刚开始用n8n的时候,我一直在找类似传统编程语言中的”全局变量”。后来发现,n8n的设计思路不太一样,它没有那种所有地方都能读写的真正全局变量,但提供了几种替代方案,各有各的适用场景。
环境变量:固定的配置项
环境变量是最接近传统意义上”全局”的东西。它是在n8n实例级别定义的,一旦设置好,所有工作流都能访问。
我主要用它来存一些固定的配置,比如API密钥、数据库连接地址、第三方服务的认证信息这些。这些东西通常不会频繁变动,而且多个工作流都需要用到。
不过要注意,环境变量修改后需要重启n8n才能生效,所以不适合存经常变的东西。
Variable Storage节点:工作流内部的临时存储
这个社区节点挺有用的。它可以在单个工作流执行期间存储和读取数据,相当于给工作流内部加了个临时的小仓库。
我经常用它来传递一些中间结果,比如在循环中维护一个计数器,或者把某个节点的处理结果暂存起来,后面几个步骤都要用到。
但这里有个坑,Variable Storage里存的数据只在当前这一次工作流运行中有效。工作流跑完了,这些数据就没了,不能当作永久存储来用。
表达式和$()语法:直接引用节点输出
这个其实是最基础的方式,也是n8n数据流转的核心。用$()语法可以直接引用上游某个节点的输出。
比如我要用HTTP Request节点的返回结果,就直接写$('HTTP Request').item.json。这种方式很灵活,想用哪个节点的数据就引用哪个节点。
我是怎么选择的
实际用下来,我总结了一套简单的选择逻辑:
- 如果是固定的配置信息,多个工作流都要用,那就用环境变量
- 如果是工作流内部要传递的临时数据,比如计数器、中间状态,用Variable Storage
- 如果只是想引用某个节点的输出,直接用表达式就行
一个重要的提醒
n8n为什么不提供真正的全局变量?我后来理解了,这其实是个好设计。真正的全局变量会让工作流之间产生隐性依赖,一旦出了问题很难排查。
n8n的这些方案都是在特定范围内共享数据,作用域清晰,出了问题也容易定位。虽然一开始可能觉得不够”方便”,但从维护和调试的角度看,这样设计更合理。
最后的思考
这些方案用熟了之后,你会发现其实比传统的那种全局变量更灵活。环境变量管配置,Variable Storage管临时数据,表达式管节点间流转,各司其职。
关键是要理解每种方案的生命周期和适用场景,用对了地方,工作流会更清晰,也更容易维护。