Function节点写代码，真的要花钱吗？
很多刚接触 n8n 的朋友，尤其是从 Zapier 或 Integromat 转过来的用户，心里总有个疑问：在 n8n 里用 Function 节点写 JavaScript 代码，会不会像其他平台那样，按执行次数或者代码行数收费？
笔者在 N8N大学 这几年，看到太多新手因为担心费用问题，不敢放手去用 Function 节点，甚至在复杂的自动化流程里硬凑逻辑，结果把流程搞得臃肿不堪。
今天，我就来帮大家彻底吃透 n8n 的收费政策，并给出几种超越 Function 节点的硬核替代方案。
官方政策解读：Function节点完全免费
先说结论：**在 n8n 中使用 Function 节点编写 JavaScript 代码，是完全免费的。**
这和 n8n 的核心商业模式有关。n8n 主要通过两种方式盈利：
- SaaS 云服务 (n8n.cloud)：按工作流执行次数收费。
- 企业版 (Self-hosted)：按席位收费，提供高级权限管理和 SSO 支持。
但无论是哪种付费模式，Function 节点本身的调用都包含在基础的执行配额里，并不会因为你写了更复杂的逻辑、调用了更多的 JavaScript 方法而额外加钱。
相比之下，Zapier 的 Code 节点通常需要昂贵的付费计划才能使用，且有严格的执行时间限制。而 n8n 的开源版本（Community Edition）更是没有任何限制，你可以随意编写代码，只要你的硬件跑得动。
为什么大家会有“收费”的错觉？
既然官方明确免费，为什么还有这种误解？主要源于 n8n 的“执行次数”逻辑。
n8n 的 SaaS 版本是按月度执行次数计费的。如果你在工作流中滥用 Function 节点，导致单次运行触发了大量循环（比如写了个死循环，或者循环处理了 10000 条数据），这会快速消耗你的执行配额。
所以，新手容易误以为是“Function 节点收费”，其实是“执行次数消耗过快”。在 N8N大学 的实战经验中，合理使用 Function 节点不仅不贵，反而是性价比极高的解决方案。
Function 节点的局限性（不仅仅是收费问题）
虽然 Function 节点免费且强大，但笔者并不推荐无脑使用它，原因有三：
- 单线程阻塞：n8n 的 Function 节点是单线程运行的。如果你在里面写了一个耗时较长的计算（如复杂的加密算法或大量数据处理），会阻塞整个工作流，导致后续节点排队。
- 缺乏类型提示：在 JS 环境中写业务逻辑，没有像 Python 或 TypeScript 那样友好的类型提示，调试起来很痛苦，尤其是处理嵌套 JSON 数据时。
- 难以维护：把业务逻辑硬编码在节点里，不利于团队协作和版本管理。一旦逻辑变更，需要手动修改节点代码，风险较高。
替代方案一：使用 Code 节点（Python）
如果你觉得 JavaScript 写起来太乱，n8n 还提供了一个隐藏的神器——**Code 节点的 Python 模式**。
在 n8n 的 Code 节点设置中，你可以将语言从 JavaScript 切换为 Python。这是 n8n 官方支持的另一个语言环境。
为什么推荐？
- 代码更简洁：Python 的语法在处理数据结构（字典、列表）时非常直观。
- 生态强大：你可以直接
import pandas、import numpy进行数据分析，或者用requests发起 HTTP 请求，这在纯 JS 的 Function 节点里配置起来要麻烦得多。 - 依然免费：和 JS 节点一样，Python 节点也不额外收费。
实操建议：在 Code 节点中，输入输出依然是通过 items 对象（Python 中是字典列表）来传递。如果你习惯 Python 的数据处理逻辑，这绝对是首选替代方案。
替代方案二：集成自定义脚本节点（Custom Nodes）
对于企业级用户或重度开发者，最硬核的替代方案是开发自定义节点（Custom Nodes）。
这相当于你把 JavaScript 代码从“运行时”搬到了“编译时”。
具体做法：
- 使用 n8n 的官方 CLI 工具创建节点模板：
n8n-node-dev new。 - 在本地编写 TypeScript/JavaScript 代码，定义好输入输出参数。
- 打包并部署到你的 n8n 实例中。
优势：
- 复用性极强：写好一次，可以在所有工作流中拖拽使用。
- 可测试：你可以像写普通代码一样写单元测试，保证逻辑正确。
- 性能更好：自定义节点通常经过编译优化，执行效率高于在 Function 节点里动态解析 JS。
虽然开发门槛稍高，但一旦养成习惯，维护成本会大幅降低。
替代方案三：善用“原生节点”组合
很多时候，我们之所以打开 Function 节点，是因为我们不知道 n8n 原生节点已经能做这些事了。
案例对比：
- 字符串处理：不要急着写 JS 字符串截取。试试 Set 节点或 Aggregate 节点，配合 Expression（表达式） 语法，比如
{{ $json.field.slice(0, 5) }}，这比 Function 节点轻量得多。 - 数据转换：要把数组转成对象？试试 Aggregate 节点配合“Group By”功能，或者用 Spreadsheet File 节点做复杂的表格处理。
- HTTP 请求：如果只是调用 API，直接用 HTTP Request 节点，配合 Auth 设置，比在 Function 里写 fetch 更稳定且易于调试。
笔者建议： 养成一个习惯——当你想写 Function 节点时，先去节点列表里找一圈，看看有没有现成的节点能用。原生节点通常比自定义代码更稳定、更高效。
避坑指南：Function 节点的常见错误
即便 Function 节点免费，写代码时也容易踩坑。以下是 N8N大学 总结的两个高频错误：
1. 忘记返回数据
n8n 的 Function 节点要求必须返回数据流。如果你的代码逻辑是异步的（例如使用了 setTimeout 或者 Promise），你必须使用回调函数 callback(null, items) 来结束执行，否则节点会一直处于“转圈”状态，导致工作流卡死。
2. 数据类型混淆
n8n 内部传递的是 JSON 对象。在 JS 代码中，如果你不小心修改了数据类型（比如把字符串变成了数字，或者把对象变成了数组），下游节点可能会报错。建议在代码开头加上类型校验：
const item = $input.first();
if (typeof item.json.field !== 'string') {
// 处理逻辑
}
FAQ 常见问题解答
Q1: 在 n8n cloud 上运行大量数据的 Function 节点会额外扣费吗？
A: 不会单独针对 Function 节点扣费，但会消耗你的月度总执行次数。如果你的 Function 处理逻辑导致单次运行时间过长，可能会触发超时（默认约 300 秒），导致执行失败。
Q2: Function 节点支持 ES6 语法吗？
A: 支持。n8n 运行在 Node.js 环境中，因此支持绝大多数 ES6+ 特性，如箭头函数、解构赋值、async/await 等。但不支持 Node.js 版本不兼容的语法。
Q3: 我可以用 Function 节点访问本地文件系统吗？
A: 如果你是自托管（Self-hosted）版本，且拥有服务器权限，是可以使用 fs 模块读写文件的。但如果是 n8n Cloud 版本，出于安全沙箱限制，这是禁止的。
总结与资源
回到最初的问题：n8n Function 节点编写 JavaScript 代码是完全免费的。它不按代码行数收费，也不按逻辑复杂度收费。
但作为 N8N大学 的主编，我的建议是：免费不代表滥用。 在面对复杂逻辑时，优先考虑 Python 节点、原生节点组合，甚至是开发自定义节点，这才是构建稳健自动化流程的长久之道。
如果你想深入学习 n8n 的高级技巧，欢迎访问我们的官网 N8N大学 (n8ndx.com)，这里有更多硬核的实战教程等你解锁。
