开始聊具体节点之前我先说个自己带新人的感受很多刚开始碰 n8n 的朋友第一次打开编辑器看到左侧一长串节点列表真的会懵。n8n 的常用节点其实没有想象中那么多真正高频的翻来覆去就那么十几个而文件操作和代码执行这两类看起来最“底层”却是绝大多数实战流程绕不开的拐点。这篇指南我就按“从文件操作到代码执行”这条线把这些常用节点一个个掰开讲清楚顺带把我自己踩过的坑也标出来。适合刚学 n8n 的人也适合已经搭过一两条流程、但想系统补一补节点功课的同学。1. 先聊清楚为什么 n8n 常用节点值得系统过一遍1.1 节点在我眼里是什么n8n 的每一个节点本质上都是一个独立的小逻辑单元。触发器负责启动工作流普通节点负责加工数据而数据在节点之间流动时主要就是两类形态JSON 对象和二进制数据。你把工作流搭起来其实就是把一个个节点像水管一样串起来让数据从左往右走。我经常跟团队里的小朋友打比方n8n 的工作流就是一个快递分拣台。包裹从传送带进来一个节点负责拆包一个节点负责贴标签另一个节点负责分到不同货车。节点之间不关心上一个节点内部怎么处理只关心它给了自己什么数据、自己应该产出什么数据。想明白这一点后面看文件操作和代码执行这类节点思路会顺很多。你不需要一上来就把所有节点背下来但心里要有一张“数据流地图”什么东西进来经过哪些加工最后送到哪里去。常用节点练熟了之后搭流程基本就是拼积木。1.2 这份指南的编排逻辑从文件操作到代码执行我见过很多人学 n8n 时有个坏习惯一个节点一个节点地背文档背完还是不知道怎么串。我的建议是换一种学法按一条完整的数据主链来学先解决“文件怎么读进来、怎么写出去”再解决“中间那步代码怎么处理数据”最后用其他高频节点把这些环节串成真实可跑的流程。为什么把文件操作放在前面因为几十个真实项目里至少一半的自动化需求是对接文件读取导出的 CSV、整理日志、把处理结果写到指定目录。而代码执行节点则是这类需求里最灵活的“兜底方案”。当可视化节点的能力不够时你至少还有 JavaScript 和 Python 可以写。掌握了这两块后面再接 HTTP Request、IF 分支、定时触发都只是添砖加瓦。所以这篇指南不讲花活只讲有一线实操价值的东西文件操作记得住哪些坑代码节点怎么写才能不翻车搭配哪些节点能组成完整工作流。2. 文件操作类节点读文件、写文件以及周边配套2.1 Read/Write File 节点的核心参数n8n 的 Files 分类下最常用的是 Read/Write File、Extract From File 这些节点。其中 Read/Write File 一个节点身兼两职通过 Operation 下拉框切换“读”还是“写”。读文件时你要关心的核心参数有三个文件路径File Path这个最关键。n8n 不会帮你猜路径写相对路径时它是相对于 n8n 进程的当前工作目录而不是你本地电脑的某个文件夹。我建议直接写绝对路径比如/srv/n8n-data/orders.csv免得在不同环境下跑出奇怪的结果。数据属性名Data Property Name读出来的文件会作为二进制数据挂在 item 的某个属性上。默认情况或显式指定后后续节点才能准确找到这份文件数据。编码Encoding默认通常用 UTF-8。如果你读的文件是从 Windows 导出的偶尔会遇到 GBK 或带 BOM 的编码这时候就需要在 Options 里显式指定编码否则后边解析出来的文本就是乱码。写文件时最容易忽略的是覆盖行为。n8n 的 Write File 默认会覆盖同名文件如果只是想追加内容要先确认当前版本是否支持 Append 模式。另外写文件的路径如果不存在节点会直接报错不会好心地帮你创建目录。2.2 实际案例读 CSV、清洗数据、写回 JSON我举个例子。假设你每天会收到一个orders.csv里面是订单明细你想把它读进 n8n算一下金额再写成一个 JSON 文件归档。一条典型的流程是这样的先用 Read/Write File 节点Operation 选 ReadFilePath 填/srv/n8n-data/input/orders.csv。因为读出来的还是二进制数据接下来通常要跟一个 Extract From File 节点让它把 CSV 解析成结构化表格数据。后面再接 Code 节点或转换节点把需要的字段算好。最后再用一个 Read/Write File 节点Operation 选 WriteFilePath 填/srv/n8n-data/output/orders-result.jsonData Property Name 选择上一步产出的数据属性把结果写出去。这样设计的核心原因是n8n 里不同节点各司其职。Read/Write File 只负责把文件搬进搬出真正把二进制解析成人能读懂的 JSON靠的是 Extract From File 这类解析节点。你非要用 Code 节点自己去解析文件内容也不是不行但没必要给自己加戏。这个案例跑通之后你会发现“读文件、加工、写文件”这个套路几乎能覆盖八成以上的本地文件自动化需求。2.3 文件操作避坑手册文件类节点的坑我基本都踩过整理成几条给你参考路径写错是第一名问题。n8n 的报错信息会告诉你文件不存在但不会告诉你正确的绝对路径是什么。遇到这种情况先在服务器上手动ls一下目标目录确认 n8n 进程有权限访问。注意容器部署时的文件系统隔离。如果你的 n8n 是用 Docker 部署的Read/Write File 节点操作的是容器内部的文件系统。容器一删文件就没了。想持久化必须在启动容器时把宿主机目录挂载进容器比如-v /srv/n8n-data:/data。这个配置我在企业环境里见过太多次被漏掉。文件权限不能忽视。有些部署环境下 n8n 进程是普通用户写/root或者其他受保护目录时会报 Permission denied。最省事的方法是单独准备一个数据目录然后给 n8n 进程读写权限。中文文件名和中文内容。Linux 下中文文件名没问题但不同系统之间拷贝后偶尔会出现乱码。内容乱码多半是编码问题优先把源文件转成 UTF-8 再喂给 n8n。我自己实操时的习惯是所有文件路径统一用绝对路径并且在流程里先放一个 Manual Trigger 手动跑一次确认读出来的数据结构符合预期再设置定时。3. Code 节点让工作流跑自定义逻辑3.1 Code 节点能做什么、不能做什么n8n 的 Code 节点是一个“万能加工车间”你可以选择 JavaScript 或 Python 编写逻辑。它能做数据映射、字段计算、数组去重、日期格式化、调用简单的第三方库还能处理低代码节点很难表达的分支逻辑。但它不是万能的尤其是刚上手的人容易高估它。Code 节点运行在沙箱环境里JavaScript 模式虽然接近 Node.js但文件系统等能力是受限的Python 模式基于 Pyodide相当于在浏览器里跑一个 Python 解释器不是完整的服务器 Python 环境。你没法在里面随便pip install所有包也不能指望它直连你服务器上的某个本地数据库然后读写文件。所以听到“代码执行”这四个字千万别下意识以为它什么都能干。用 Code 节点最正确的心态是用它做“数据层”的加工不要用它做“系统层”的操作。3.2 JavaScript 模式实战JavaScript 应该是 n8n 里最常用的代码语言。它的输入是工作流传到这个节点的 items输出则是一个数组。很多人第一次写 Code 节点时会犯同一个错误直接返回一个对象结果下一个节点拿不到数据。一段很标准的 JS 代码长这样const items $input.all(); const result []; for (const item of items) { const raw item.json; const cleaned { id: raw.id, total: Number(raw.price) * Number(raw.quantity), createdAt: new Date(raw.createdAt).toISOString(), isVip: raw.orderType vip ? true : false, }; result.push({ json: cleaned }); } return result;这段代码做的事情很简单读取所有传入 item把每条数据处理成新的字段结构然后以{ json: cleaned }的形式压入结果数组。注意重点$input.all()帮你拿到全部输入item.json才是真正的业务数据最后返回的一定是数组数组里的每一项都必须包一个json字段。如果你只是想拿第一条数据可以用$input.first().json想遍历全部就老老实实用$input.all()。我刚接触那会儿图省事总是只处理第一条结果后面的数据全被吞了查了半天才发现是返回值结构的问题。3.3 Python 模式实战Python 模式和 JS 模式的目标一致只是语法不同。n8n 的 Python Code 节点里输入变量一般叫items或通过input.all()获取返回值同样是包含json字段的列表。下面是一段和刚才 JS 例子等价的 Python 代码items input.all() result [] for item in items: raw item[json] cleaned { id: raw.get(id), total: float(raw.get(price, 0)) * int(raw.get(quantity, 0)), createdAt: raw.get(createdAt), isVip: raw.get(orderType) vip, } result.append({json: cleaned}) return result写 Python 模式时有几个实际体会想分享用.get()访问字段比直接raw[price]安全得多缺失字段时会先返回默认值不会整个流程崩掉。数值型字段不要默认它是数字。CSV 解析出来的字段常常是字符串所以代码里显式float()和int()转换是常态。Pyodide 环境对内存和包支持有限别在代码节点里加载超大文件或重型数据处理框架。测试代码时你可以先只写return [{json: {test: True}}]跑通链路再逐步加上真正的业务逻辑排错会轻松很多。3.4 Code 节点的执行边界与性能建议我在生产环境里用 Code 节点时给自己定过几条规矩第一单条数据处理好说但一次处理几千上万条记录时别在循环里做耗时很长的同步请求。Code 节点不是调度中心大并发和高延迟场景应该交给消息队列或外部服务。第二不要在 Code 节点里尝试读写本地文件。n8n 沙箱对文件系统的限制是故意的强行绕过去既不稳定也不安全。真要和文件打交道就用 Read/Write File 节点把文件操作留在它该在的地方。第三异常处理一定要做。JavaScript 里用try...catchPython 里用try...except。因为 n8n 里 Code 节点一旦抛异常整个分支都会变红后续节点直接不执行。把错误信息放到返回值里比让节点黑屏报错要好排查得多。第四代码写完后在节点旁边放一个 Sticky Note记录这段逻辑的版本和主要依赖。这个小动作在团队协作时能省掉很多沟通成本。4. 其他高频节点的搭配与选型4.1 HTTP Request把工作流接到外部系统如果说文件操作解决的是“本地数据进出”那 HTTP Request 节点解决的就是“远程系统对接”。你想调用某个 API、拉取订单列表、推送告警基本都是靠它。HTTP Request 节点支持 GET、POST、PUT、DELETE 这些常见方法响应里的 JSON 通常会自动解析成 item 供下游使用。配置时URL 直接写请求地址Headers 和 Body 按需填需要登录鉴权时就在 Credentials 里维护账号信息而不是把密钥硬编码到 URL 里。我建议所有涉及密钥的请求都优先配置 n8n credentials。这样既能统一管理又可以在不同工作流里复用真要换密钥时只改一处就够了。每次排查 401 或 403 时先打开认证配置看一眼能少走很多弯路。4.2 IF / Switch流程分支的正确姿势不是所有流程都是直线。数据走到某个节点后你总得判断一下金额大于零走这一路等于零走另一路类型是 A 走左边是 B 走右边。这就是 IF 和 Switch 节点存在的意义。IF 节点适合单条件的二分支判断。它有两个出口true 和 false。比如上一个 Code 节点计算出了total你可以在 IF 里配置条件total 0大于 0 的记录继续处理等于 0 的记录丢弃。Switch 节点更适合多路分发。你可以根据一个字段的多个取值路由到不同的分支。比如根据orderType字段把订单分流到“普通单”“会员单”“售后单”三条线路。节点选型上没有绝对标准我的经验是条件少用 IF条件多、值域明确用 Switch逻辑复杂时把分支条件收敛到 Code 节点里处理。4.3 触发器们Schedule Trigger、Webhook 和 Manual Trigger一个工作流要跑起来必须有触发器。最常见的是这三种Schedule Trigger定时触发器按固定时间或 CRON 表达式触发工作流。适合日报生成、定时数据同步这种场景。配置时特别注意时区n8n 实例默认时区和你所在的时区不一定一致我就是因为没设时区流程总是“早了一个小时”跑。Webhook网络钩子触发器由外部系统调用你提供的 URL 来触发工作流。适合接收第三方的回调推送。配置好后会生成一个 URL把这个 URL 给上游系统即可。Manual Trigger手动触发器只在编辑器里手动点击“Execute Workflow”时触发。这是我调试流程时最常用的方式搭任何流程都先放一个它跑通不要直接上定时。4.4 常用节点选型速查表节点主要用途我通常在什么时候用Read/Write File读、写服务器本地文件文件需要落地、归档、读取或和外部脚本交换数据Extract From File把二进制解析成结构化数据Read/Write File 读入 CSV、JSON 之后Code自定义 JS/Python 逻辑字段加工、格式转换、复杂分支、组合数据HTTP Request调用外部 API拉数据、推数据、对接业务系统IF单一条件二分支判断数据是否满足某个规则Switch多条件多路分发按枚举值把数据送到不同分支Schedule Trigger定时触发日报、周期同步、定时清理Webhook外部 HTTP 回调触发接收业务系统的实时推送这张表不是一个死规则但它能帮你快速定位突然不知道该选什么节点时对着表格过一遍比翻文档快很多。5. 完整实战从文件读取到代码处理再到结果输出5.1 场景设定与整体流程光讲节点太散我把它们串成一个完整可复现的场景。假设你在做一个数据运维的小任务每天早上 9 点n8n 自动读取服务器上/srv/n8n-data/input/orders.csv清洗订单数据计算每条订单的实付金额过滤掉金额为 0 的无效记录把有效结果写到/srv/n8n-data/output/orders-today.json然后通过 Webhook 通知运营群。整体流程是这样串的Schedule Trigger 每天 09:00 触发工作流。Read/Write File 读取orders.csv。Extract From File 把 CSV 解析成结构化数据。Code 节点计算实付金额整理输出字段。IF 节点过滤无效订单。Read/Write File 写入 JSON 结果。HTTP Request 发送通知到 Webhook 地址。思路本质上就是“读文件 - 处理 - 写文件 - 通知”。你以后搭其他流程也完全可以按这个套路套只是中间步骤换一换。5.2 每个节点的配置细节第一步Schedule Trigger。时间设为每天 9 点CRON 表达式就填0 9 * * *同时确认时区设置正确。第二步Read/Write File。Operation 选 ReadFilePath 写死/srv/n8n-data/input/orders.csvEncoding 保持默认 UTF-8。这一步会从文件中读出二进制数据。第三步Extract From File。这里选择解析类型为 CSV让它把上一步的二进制数据变成表格行。配置完后可以先手动执行一次看输出的字段名是不是id、price、quantity、orderType这些。第四步Code 节点。用之前 JavaScript 示例里的代码把total计算出来。除了计算金额我还习惯把id转成字符串、把时间字段格式化成标准 ISO 格式这样写出去的 JSON 干净很多。第五步IF 节点。配置条件为total大于 0。这样金额为 0 的订单会进 false 分支有效数据从 true 分支继续走。第六步Read/Write File写文件。Operation 选 WriteFilePath 填/srv/n8n-data/output/orders-today.jsonData Property Name 选上一步 IF 节点 true 分支输出的数据属性。这里的默认行为是覆盖写如果你需要保留历史文件就得在流程里做一下文件改名或追加。第七步HTTP Request。用 POST 方式把汇总结果发到 Webhook 地址Body 里引用前面加工后的 JSON 数据。这样运营群里就能看到当天的处理结果。5.3 流程跑完后的排错记录这个流程我第一次搭时也翻过车记录几条最典型的IF 节点的 false 分支一直在空跑。其实不是空跑是 IF 节点把不符合条件的记录也继续往下传了只是后续没有接节点。后来我在 false 分支后面接了一个 NoOp 或直接断开才把流程理清楚。Code 节点计算出来后下一步拿不到我想要的字段。原因是我一开始返回了result.push(cleaned)漏了{ json: cleaned }包装。这类问题只要把返回值结构打印出来看一遍立刻就能发现。写文件时报目录不存在。我一开始想当然填了一个没创建过的路径后来在服务器上手动mkdir -p建好目录再把路径填进去就好了。n8n 不会帮你创建目录这一点一定记住。6. 常见问题与排查技巧实录6.1 问题速查表最后把我在实际使用中常遇到的问题整理成一张表你可以直接收藏。症状常见原因排查方法Read/Write File 报文件不存在路径写错或相对路径基准不对改成绝对路径在服务器上先确认文件存在读文件后中文乱码源文件不是 UTF-8 编码通过节点 Options 指定正确编码或先转换源文件编码Extract From File 解析出来的字段为空文件格式和所选解析类型不匹配手动打开文件看前几行确认分隔符、标题行Code 节点执行后下游没有数据返回的不是数组或缺json字段包装把返回值结构打印出来检查return的内容IF 节点过滤后仍然有数据走到后边误接了 false 分支明确 true/false 分支各自接什么节点定时触发后找不到文件容器文件系统没有挂载宿主机目录调整 Docker 卷挂载配置确认路径映射HTTP Request 始终报认证失败Credentials 或 Header 配置不对检查响应体里具体的错误信息逐项核对认证参数Code 节点运行很慢或内存爆掉一次处理太多数据或循环里有耗时操作拆小批次或把重活交给外部服务6.2 我踩过几次坑之后积累的心得我自己实际用下来最值钱的一条心得是不要等流程报错才去研究节点先把常用节点的行为习惯摸清楚搭流程会快很多。文件操作类节点请一定用绝对路径并提前把目录和权限准备好代码执行节点先把最简单的返回结构跑通再往上叠业务逻辑所有涉及密钥的请求规规矩矩存到 credentials 里别图省事硬编码。还有一个小小的经验任何一个稍微复杂的流程都值得在关键节点后面临时挂一个 Set 节点或者直接打印输出看到中间结果再往后走。很多“莫名其妙”的问题80% 是节点返回值结构不对20% 是路径、权限、编码这些基础配置没做好。把这些基本功练好n8n 在你手里就会从“能跑”变成“稳跑”。