场景导入：别再让“复制粘贴”害死你的发布流程
笔者在 N8N 大学社区里，见过太多同学在开发和生产环境之间反复横跳。最常见的惨案是什么？开发环境测得好好的，一发布到生产环境，API 请求立马报 401 Unauthorized。
追根溯源，往往不是代码逻辑错了，而是忘了把测试环境的 API Key 换成生产环境的。这种手动修改配置的方式，不仅效率低下，而且极容易出错——这正是“配置地狱”的典型特征。
作为 N8N 大学的首席主编，今天我要教大家一个硬核技巧：利用 N8N 的 $env 变量配合 Credentials（凭据），实现不同环境（Dev/Prod）API Key 的动态切换。这一招，能彻底根除手动修改配置的风险。
准备工作：给你的工作流装上“导航仪”
在动手之前，请确保你手头有以下资源：
- N8N 环境：可以是官方云服务，也可以是自己部署的 Docker 版本（推荐 Docker，方便设置环境变量）。
- 两套 API Key：一套用于开发（Dev），一套用于生产（Prod）。比如 OpenAI、飞书或任意第三方服务的 Key。
- 终端/Docker 管理权限：用于设置环境变量。
核心实操：三步实现动态凭据切换
我们以一个简单的场景为例：根据当前环境，自动选择对应的 API Key 发送 HTTP 请求。
第一步：设置全局环境变量 (The $env Setup)
N8N 允许你在启动服务时注入环境变量。这就好比给你的工作流定义了一个“当前模式”的开关。
如果你使用 Docker 部署，可以在 docker-compose.yml 中添加：
environment:
- NODE_ENV=production # 或者 development
- MY_API_KEY=prod_key_123456
- MY_API_KEY_DEV=dev_key_654321或者在运行容器时直接传递：
docker run -it --rm
-e NODE_ENV=production
-e MY_API_KEY=prod_key_123456
-p 5678:5678
docker.n8n.io/n8nio/n8n笔者注：这里我们使用了 NODE_ENV 作为环境判断依据，这是业界通用的标准做法。
第二步：创建“动态凭据” (Dynamic Credentials)
这是最关键的一步。我们需要创建一个凭据，但它的值不是写死的，而是引用环境变量。
- 进入 N8N 面板，点击左侧的 凭据 (Credentials)。
- 新建一个凭据，类型选择 Generic Credentials 或者你具体服务的类型（如 HTTP Request）。
- 在 API Key 的输入框中，不要直接填入
prod_key...，而是填入以下表达式：
{{ $env.NODE_ENV === 'production' ? $env.MY_API_KEY : $env.MY_API_KEY_DEV }}原理解析：
N8N 的凭据框支持表达式。上述代码的意思是：如果环境变量 NODE_ENV 等于 production，就使用 MY_API_KEY；否则，使用 MY_API_KEY_DEV。
这样，无论你在哪个环境运行工作流，这个凭据都会自动“变身”。
第三步：在工作流中调用并验证
现在，让我们回到工作流画布。
- 拖入一个 HTTP Request 节点。
- 配置 URL（例如：
https://api.example.com/user）。 - 在 Authentication 选项中，选择 Generic Credentials Type。
- 在下方的 Credentials for Generic 下拉菜单中，选择刚才创建的“动态凭据”。
点击执行测试一下：
如果你的 N8N 当前运行在 NODE_ENV=development 模式下，请求会自动带上开发 Key；如果部署到生产服务器并设为 production，则自动切换为生产 Key。
避坑指南：实战中的两个大坑
虽然原理简单，但新手最容易在细节上翻车。笔者特意整理了两个常见问题：
1. 凭据的“缓存”陷阱
现象：你修改了 Docker 的环境变量重启了容器，但在 N8N 界面里测试，发现它还在用旧的 Key。
原因：N8N 的凭据在加载到内存后，有时不会立即刷新，尤其是当你在 UI 里手动触发测试时。
解决：修改环境变量后，建议彻底重启 N8N 容器。如果在 Workflow 中测试，确保点击的是“执行工作流”（Test workflow），而不是仅仅打开节点预览。
2. 变量命名冲突
现象：表达式报错，提示找不到变量。
原因：在 Docker 或 Linux 环境中，环境变量通常对大小写敏感，且不支持特殊字符。如果你在环境变量里写了 MY-API-KEY，在表达式里调用时可能需要写成 $env['MY-API-KEY'] 或者统一改为大写/下划线命名。
建议：养成好习惯，环境变量统一使用 大写 + 下划线 命名法（如 API_KEY_DEV），既规范又不容易出错。
FAQ 问答
Q1: 如果我不使用 Docker，而是直接在服务器上运行 Node.js，怎么设置环境变量？
A: 在启动命令前加上变量即可。例如：
NODE_ENV=production MY_API_KEY=xxx node index.js
或者使用 PM2 等进程管理工具，在 ecosystem 配置文件中配置 env 字段。
Q2: 这种方法支持数据库连接字符串吗？
A: 完全支持！MySQL、PostgreSQL 等数据库凭据，同样可以在连接字符串或密码字段中使用 {{ $env.DB_PASSWORD }} 进行动态注入。
Q3: 我想在工作流节点内部获取环境变量，除了凭据还有别的方法吗？
A: 当然。在任何支持表达式的节点（如 Set 节点或 IF 节点）中，你都可以直接使用 {{ $env.VARIABLE_NAME }} 来读取值并传递给下流节点。
总结与资源
配置中心化是企业级自动化的基石。通过 $env 环境变量与 N8N 凭据的结合，我们不仅解决了多环境切换的痛点，更为工作流的安全性上了一把锁——敏感的 API Key 再也不需要裸露在可视化的编辑器里了。
我是 N8N 大学的主编，希望这篇实战指南能帮你构建更健壮的自动化系统。如果觉得有用，欢迎分享给身边正在折腾自动化的朋友们。
