做 n8n 工作流做得多了你会发现真正把人卡住的往往不是节点怎么连而是表达式怎么写。尤其是想把机器学习这类场景塞进自动化流程里时模型参数、阈值、版本号、特征数组这些东西总不能写死在节点里一旦要换环境、调参数、改格式整个人就被硬编码绑架了。n8n 表达式和函数就是用来解决这个问题的关键工具它让你在节点之间动态生成配置、灵活做复杂数据转换把“写死”变成“算出来”。这篇文章我打算围绕一个非常具体的诉求来写如何在 n8n 里用表达式与函数实现机器学习场景下的动态配置以及面对嵌套 JSON、数组聚合、字段清洗这类复杂数据转换时表达式到底能写到什么程度、哪些事应该交给 Code 节点或专门的节点。无论你是刚接触 n8n 的新手还是已经在搭企业级自动化流程的老手只要你需要在工作流里动态传参、批量转换数据这篇内容应该能让你少踩不少坑。1. 先搞清楚n8n 表达式在机器学习工作流里到底解决什么问题1.1 “动态配置”的本质把硬编码变成运行时求值先说一个我经常看到的误区很多人把 n8n 当成一个“连线工具”觉得把节点拖出来、连上线、填好参数工作流就能跑了。遇到机器学习相关需求时他们会在 HTTP Request 节点里写死模型 URL在参数里写死 temperature、top_k、batch_size甚至在 IF 节点里写死阈值 0.8。这些值一旦需要变化就要进编辑器里改节点参数。你可能会想改参数就改参数呗反正也不频繁。但真实业务里模型版本要灰度、A/B 测试要切流量、不同客户要不同阈值、不同环境要用不同的 API Key这些需求叠加在一起硬编码的工作流根本维护不住。动态配置的本质就是把这些“运行时才会确定”的参数变成表达式。n8n 的表达式写在双大括号{{ }}里本质是一段 JavaScript 表达式它在工作流执行到该节点时被求值。你可以引用上游节点的输出、环境变量、当前时间、甚至是节点内部的固定参数然后拼接、计算、格式化最终得到一个字符串、数字或对象。比如说你要调用一个文本分类服务模型版本是上游节点返回的阈值是环境变量里配置的那么 HTTP Request 的 body 完全可以写成这样{ model: {{ $json.modelVersion }}, texts: {{ $json.texts }}, threshold: {{ $env.CLASSIFY_THRESHOLD }} }工作流跑起来的时候n8n 会逐个计算出$json.modelVersion的值、$env.CLASSIFY_THRESHOLD的值再填到请求体里。这就叫运行时求值。真正的好处是模型切版本不用改工作流改上游数据库或环境变量就行阈值调优不用发版改配置就行。我自己的经验是动态配置要尽量遵循一个原则常量进环境变量或者工作流参数变量进上游节点数据格式转换交给表达式。这样每一层职责清晰出问题也好定位。1.2 复杂数据转换的本质表达式就是工作流里的“计算器 转换器”说完动态配置再说复杂数据转换。n8n 的节点与节点之间传递的是结构化 JSON 数据。比如 Webhook 节点收到一条 Webhook 请求里面是一大段嵌套 JSON数据库节点查出来的是一个数组HTTP Request 节点调完外部 API返回的可能是一个带data、meta、errors多层结构的对象。但下游节点往往只关心其中某几个字段或者需要把字段转换成特定格式。比如机器学习服务要求输入是固定顺序的数值数组可上游接口返回的是带 key 的对象比如模型要的特征是清洗后的无空格小写字符串可原始数据里有换行和非法字符又比如你需要把三天的日志聚合成一个统计向量再传给模型做预测。这些操作看起来不起眼但却是整个自动化流程里最容易出错的地方。n8n 表达式在这里扮演的角色就是工作流里的“计算器 转换器”它让你在不写完整代码的情况下完成字段抽取、数值计算、字符串拼接、数组变换、条件选择。很多人一想到转换复杂数据第一反应是拖一个 Code 节点写 JavaScript。这当然可以而且我也经常这么做。但表达式的优势在于它可以直接写在节点参数里不用额外增加节点也不会打断流程的可读性。尤其是“只是取一个字段”“只是拼个字符串”“只是判断一下空值”这种轻量任务用表达式比用 Code 节点清爽得多。这里插一句。搜索“n8n 表达式”的时候经常会看到“表达式必须包含类类型”之类的词那其实是 Java、C# 这类静态语言编译器抛出来的错误不是 n8n 环境里的报错。n8n 表达式就是 JavaScript 表达式它没有“类类型”“类对象”这种概念。你不需要去背什么波兰表达式、表达式树那些是编译原理里的东西跟你在 n8n 里写{{ $json.name }}完全不是一回事。n8n 里你只要理解两件事双大括号里面是一段会被求值的 JavaScript 表达式表达式的最终结果会替换掉外面那一层字符串。2. 动态配置实战用手写表达式替代“每次改参数”2.1 动态请求体与模型参数组包先说一个最常见的场景调用外部机器学习 API。不管你是调用云厂商的 NLP 服务还是调用团队自己部署的 FastAPI 推理服务流程都差不多准备请求体、发送请求、解析响应。请求体里的参数往往不是写死的而是由上游业务数据决定的。举个例子。假设你有一个客户评分模型服务接口接收的参数是customer_id、features一个长度为 8 的数值数组、model_version和threshold。如果上游节点已经查询出了客户资料数据库节点输出类似这样的 JSON{ customer_id: C10086, age: 34, income: 25000, credit_score: 720, active_months: 18, total_orders: 42, avg_order_value: 326.5, return_rate: 0.08, support_tickets: 2 }你要构造请求体最简单的方式是在 HTTP Request 节点的 Body 参数里用 JSON 格式配合表达式{ customer_id: {{ $json.customer_id }}, features: [ {{ $json.age }}, {{ $json.income }}, {{ $json.credit_score }}, {{ $json.active_months }}, {{ $json.total_orders }}, {{ $json.avg_order_value }}, {{ $json.return_rate }}, {{ $json.support_tickets }} ], model_version: v2, threshold: {{ $env.SCORE_THRESHOLD }} }这一步的关键是理解$json对象。在 n8n 里$json代表“当前节点的输入数据”通常是上一个节点输出的第一条数据。表达式中写{{ $json.income }}就是把输入里的income字段值取出来填进去。很多人第一次写这种表达式会犯一个错误在数组里写[{{ $json.age }}, {{ $json.income }}]时如果上游字段里有字符串拼出来的 JSON 就是非法的。比如字段credit_score在数据库里是字符串类型那表达式结果可能是720组包后变成[720]机器学习服务端直接报类型错误。踩过这个坑之后我的习惯是在组包之前先确认上游字段类型或者干脆用{{ Number($json.credit_score) }}这类显式转换把数值统一转成 number。表达式里是可以写函数的Number()、String()、parseFloat()、Math.round()都可以用。2.2 环境变量、工作流参数和模型版本切换动态请求体只是第一步。真正让工作流变得“可配置”的是把那些经常变、但不该被普通用户碰的值放到环境变量或工作流参数里。n8n 的表达式支持用$env访问环境变量。举个例子。同一个工作流你在开发环境调用的是https://dev-model.example.com/predict生产环境调用的是https://prod-model.example.com/predict。如果你把 URL 写死在 HTTP Request 节点里每次部署都要改工作流非常容易出错。正确做法是在环境变量里配置ML_ENDPOINThttps://dev-model.example.com/predict ML_MODEL_VERSIONv2 ML_CONFIDENCE_THRESHOLD0.85然后在 HTTP Request 节点里这样写{ url: {{ $env.ML_ENDPOINT }}, body: { model: {{ $env.ML_MODEL_VERSION }}, threshold: {{ $env.ML_CONFIDENCE_THRESHOLD }} } }这样开发、测试、生产环境切换时只需要改环境变量工作流本身完全不用动。这是我在企业级部署方案里最常用的一招把环境相关配置全部外部化工作流里只保留业务逻辑。除了环境变量n8n 的节点参数本身也可以当作“静态配置”来用。在表达式里你可以用$parameter获取当前节点的参数值也可以把工作流级的某个固定值通过 Set 节点或多个分支传递下去。不过我更推荐的做法是把“业务上允许随时人工调整的参数”写成工作流里的第一个 Set 节点作为一个“配置区”后面的节点统一引用这个配置区里的值。比如一个定时推理工作流每天跑一次batch size 和模型版本会频繁调整。我习惯在工作流最前面放一个 Set 节点手动设置{ batch_size: 64, model_version: v3, use_cache: true }后面所有用到这些参数的地方统一写{{ $node[配置区].json.batch_size }}。这样调整参数时只需要打开工作流改第一个节点的值不用去几十个节点里翻表达式。这里要注意一个细节跨节点引用时表达式要写完整路径。$node[配置区].json.batch_size的json就是该节点输出数据的属性。如果你用了多个输出分支还需要指定第几条写法是$node[配置区].json[0].batch_size。具体用哪种取决于你节点的连接方式建议在表达式编辑器里点选自动生成不要手写。2.3 用 Cron 表达式控制模型定时任务以及动态调度的替代方案机器学习工作流里有一类非常典型的定时场景每天凌晨跑批量推理、每整点同步一次模型文件、每周一重新计算特征缓存。n8n 的 Schedule Trigger 节点支持 Cron 表达式这是很多人在第一次配置时头大的地方。Cron 表达式是一个由 5 个星号分隔的字段分、时、日、月、星期。比如每天凌晨 2 点 30 分跑批量任务写法是30 2 * * *每周一早上 8 点整同步模型写法是0 8 * * 1。我先把常见场景列一个速查表含义Cron 表达式每小时整点执行0 * * * *每天凌晨 2 点 30 分执行30 2 * * *每周一 8 点执行0 8 * * 1每月 1 号 0 点执行0 0 1 * *每个工作日 9 点执行0 9 * * 1-5每 15 分钟执行一次*/15 * * * *Schedule Trigger 节点在配置 cron 时通常是把表达式作为一个固定字符串填在界面里。如果你希望通过工作流的计算结果来“动态决定下一次执行时间”那是做不到直接用表达式的因为调度器在启动时就需要知道 cron 表达式它不会在每次执行完后再重新求值。那动态调度怎么办我有两个替代方案。第一个是“Wait 节点循环法”用一个 Code 节点计算出下一次等待的毫秒数再交给 Wait 节点等待执行完后又回到同一个判断逻辑。第二个是“外部触发法”由外部定时系统比如操作系统的 cron按固定节奏调用 n8n 的 WebhookWebhook 入口再根据当前业务参数决定是否继续执行。这两个方案我都用过后者更稳定也更容易监控。顺带说一句定时任务里经常要计算“昨天”“上周一”“本月第一天”这类时间。表达式里可以用new Date()配合时间戳来做。比如批量推理要处理昨天 0 点到 24 点的数据可以这样写起始时间{{ new Date(new Date().setHours(0,0,0,0) - 86400000).toISOString() }}这个表达式先拿到今天的 0 点减去一天的毫秒数得到昨天 0 点再转成 ISO 字符串。虽然看起来绕但效果很稳定。3. 复杂数据转换实战从嵌套 JSON 到干净特征3.1 数组扁平化、去重与统计很多机器学习 API 接收的输入不是单条数据而是一个数组。比如你要把用户过去 30 天的行为日志聚合成特征向量再传给模型。上游数据库查询节点返回的数据可能长这样[ { action: view, count: 3 }, { action: click, count: 5 }, { action: view, count: 2 }, { action: purchase, count: 1 } ]而模型要求的输入是固定长度的数组[总访问次数, 总点击次数, 总购买次数]。这时候就需要做两件事按类型分组求和把结果按固定顺序排列。n8n 表达式里的 JavaScript 数组方法是完整的map、filter、reduce都能用。下面这个表达式可以算“总 view 次数”{{ $json.filter(item item.action view).reduce((sum, item) sum item.count, 0) }}但是注意$json在 n8n 的普通表达式里通常代表“当前这条数据”。当上游节点返回的是数组时表达式的$json默认可能是数组本身也可能需要你用$input或$items()来访问完整的列表。这一点在不同版本里行为不完全一致最稳妥的做法是先加一个日志节点输出看看结构再写表达式。我的经验是如果你需要对“整个数组”做跨行聚合直接用 Code 节点可能更清晰因为表达式的$json语义容易把人绕晕。但如果你只是对“当前这条数据的某个字段”做数组内部的变换表达式写起来反而更快。比如当前这条数据是一个对象对象里有个tags数组字段你希望把它去重后拼成逗号分隔的字符串这个表达式就可以直接写在输出字段里{{ [...new Set($json.tags)].join(,) }}展开运算符把数组展开到 Set 里去重再转回数组最后 join 成字符串。这个写法简洁而且不需要额外节点。3.2 嵌套 JSON 抽取、字段改名与正则清洗接下来是嵌套 JSON。外部 API 返回的数据往往裹了很多层比如{ status: ok, data: { result: { prediction: 0.9234, meta: { model_version: v2, latency_ms: 35 } } } }如果你只是想拿到prediction值表达式可以写成{{ $json.data.result.prediction }}。但难点在于不是每条返回都有data.result。如果外部服务报错了返回的结构可能变成{ status: error, error: { code: 500, message: timeout } }这时候直接访问$json.data.result.prediction就会报错。我的处理习惯是先判断是否存在再决定取值。表达式里可以写三元表达式{{ $json.data?.result?.prediction ?? $json.error?.message ?? unknown }}?.是可选链遇到空值返回 undefined 而不是抛异常??是空值合并前面是 null 或 undefined 时就取后面。这样写既安全又简短。如果你面对的是不熟悉 n8n 表达式的同事我建议把这个写法多注释说明一下因为?.和??看起来确实有点抽象。字符串清洗也是高频需求。机器学习模型对输入文本通常很敏感比如不允许有换行符、不允许有重复空格、大小写必须统一。这个用表达式可以轻松处理{{ $json.text.trim().replace(/\s/g, ).toLowerCase() }}这里的replace(/\s/g, )会把所有连续空白字符包括换行、Tab替换成单个空格配合trim()去掉首尾空格最后统一转小写。如果还想做更复杂的清洗比如去掉特殊字符可以换成replace(/[^a-zA-Z0-9\u4e00-\u9fa5]/g, )。有一个小坑要提醒n8n 表达式里写正则时反斜杠\的转义规则和普通 JavaScript 不太一样。你在表达式编辑器里写\s时编辑器可能会把它当成合法的正则字符但如果表达式是通过外部 JSON 配置传入的需要写成\\s才能转义成功。遇到正则没生效的问题先检查是不是反斜杠层数不对。3.3 日期、编码与安全转换以及为什么签名计算不应该用表达式数据处理还有一个常见场景日期格式统一、Base64 编码、URL 编码、字符串与 JSON 互转。这些操作在 n8n 表达式里都有对应的实现方式。日期格式统一是模型服务里很常见的需求。比如上游给的日期是时间戳、ISO 字符串、甚至是2025/03/18这种格式而模型特征里要求统一用YYYY-MM-DD。你可以用new Date()先解析再手动拼接{{ new Date($json.date).toISOString().slice(0, 10) }}这个表达式先把日期解析成标准 ISO 字符串然后取前 10 个字符得到2025-03-18。简单直接。缺点是时区问题toISOString()用的是 UTC 时间如果你的业务在东八区凌晨的数据会被算到前一天。这种情况下我更推荐用 Code 节点配合时间库或者先用一个专门处理日期的节点。JSON 与字符串互转也很常用。当你需要把整个对象传给下游节点时有时对方要求的是一个 JSON 字符串而不是对象{{ JSON.stringify($json.data) }}反过来当你接收到的是一个 JSON 字符串需要取其中一个字段时{{ JSON.parse($json.rawBody).model_version }}JSON.stringify和JSON.parse是两个最基础也是最有用的函数几乎每个复杂工作流都会用到。但要注意如果字符串本身不是合法 JSONJSON.parse会直接抛异常。所以稳妥的做法是先判断是否能解析或者用 try/catch 逻辑把它包起来。纯表达式里没法写 try/catch这种情况下我会把整段逻辑挪到 Code 节点。最后说一个很多人踩过的坑给外部 API 做 HMAC 签名。有一些模型服务会在请求头里校验签名很多人试图在表达式里完成签名计算但 n8n 表达式上下文里并没有内置的 crypto 函数你很难在双大括号内直接算出一个 SHA256 HMAC。我踩过这个坑后就养成了规则凡是涉及加密、签名、复杂哈希的直接用 Crypto 节点或者 Code 节点不要硬塞进表达式。Crypto 节点可以很方便地生成 HMAC只要选择算法、填好密钥和消息就行。Code 节点里也可以用 Node.js 的 crypto 模块。表达式擅长的是“计算和转换”不是“密码学操作”。4. 高频报错与排查技巧实录4.1 常见报错成因与解决表达式写多了总会遇到报错。我把自己遇到最多的几种情况整理成一张表方便你排查时对照报错现象常见原因解决思路Cannot read properties of undefined访问了不存在的字段或上游节点输出结构和预期不一致用?.可选链或在前面加日志节点确认结构Invalid expression双大括号语法错误、括号不匹配、非法字符把表达式拆开先写最小片段测试输出结果是默认文本表达式被当成纯字符串没有用双大括号包住在参数值里写{{ }}不要在 JSON 的 key 位置写表达式时间结果差一天使用了 UTC 相关方法检查toISOString()、getTime()是否受时区影响正则替换没生效反斜杠转义层级的问题尝试把\s改为\\s或改用 Code 节点表达式求值顺序不对没有注意运算符优先级字符串拼接和数字相加混在一起加括号明确优先级数值字段显式用Number()还有一个很隐蔽的问题我之前反复遇到表达式里用引号时容易跟外层的引号冲突。在 n8n 的 JSON 参数里字符串值用双引号包裹如果你的表达式内部也用了双引号字符串就会导致 JSON 解析出错。解决办法是表达式内部尽量用单引号。比如{{ $json.text.split(、)[0] }}这种写法在 JSON 参数里很危险建议改成{{ $json.text.split(、)[0] }}。4.2 从日志到结构一套可复制的排查流程表达式报错最气人的地方在于信息量太少。好在排查流程是可以标准化的我现在的习惯是四步走。第一步先看输入。在报错节点前面加一个日志节点把上游输出完整打印出来。很多问题根源根本不是表达式写错而是你以为的字段名和实际字段名不一样。比如数据库查询结果里字段名带了大写你写的是小写自然取不到值。第二步简化表达式。把你的长表达式先替换成一个短表达式比如{{ JSON.stringify($json) }}确认最基础的取值没问题再逐步把处理逻辑加回去。这样做的好处是把变量一个个隔离出来不至于同时面对多个问题。第三步分段测试。n8n 的表达式编辑器支持实时预览选一个测试数据看看表达式结果是什么。如果结果和预期差得很远就在表达式里多用几个临时函数查看中间值。虽然没法直接断点调试但分段拼出中间结果是可以做到的。第四步固定基线。每次改完表达式记录一份“输入示例 期望输出 实际输出”。我自己维护了一个测试数据集合专门用来验证表达式改动。首次调试我建议用真实数据跑一遍然后把这个输入保存下来放在一个固定的测试 Webhook 里随时可以重放。排查时还有一个非常实用的技巧如果你不确定某个表达式在 n8n 里的具体行为可以先在浏览器控制台里用 JavaScript 模拟一遍。因为 n8n 表达式核心是 JavaScript除了一部分 n8n 特有的对象比如$json、$node之外纯 JS 的部分在控制台里跑的结果跟在 n8n 里基本一致。5. 把表达式写得像代码一样可维护5.1 命名与分层好的表达式也应“可读”工作流维护成本一大半来自看不懂的表达式。我见过那种写了几百字符、全是括号和链式调用的表达式跑起来完全正常但三个月后回去看根本不知道当初在算什么。所以我给自己定了几个朴素规则。规则一表达式只做“一步复杂”。如果一次转换需要拆成两步就中间用一个 Set 节点过渡而不是硬把两步合在同一个表达式里。比如先抽取字段、再清洗字符串分两个节点各写一个表达式虽然节点多了但每一步都能单独测试。规则二字段命名要贴近业务。上游节点在导出数据时如果字段名是a、b、c后面表达式里写$json.a看着就头大。我习惯在数据入口处用 Set 节点做一次“翻译”把a改成user_age、b改成purchase_count。这相当于给数据做了一层 DTO 映射后面所有表达式都基于清晰字段名书写。规则三常用配置集中管理。把工作流的模型版本、阈值、开关、URL 这类参数统一放在工作流最前面的“配置区”节点里。后期改参数只需要到这个节点去改表达式里全部用引用。这样做还有一个好处你可以在配置区里写注释说明每个参数的作用这对团队协作尤其重要。5.2 什么时候该用 Code 节点而不是表达式这个边界很多人把握不好。我的经验是表达式擅长“参数级求值和轻量转换”Code 节点擅长“完整的数据处理流程”。如果你发现一个表达式已经长得像天书或者你需要写 for 循环、try/catch、多步中间变量那就停下来换成 Code 节点。具体来说优先级这样判断单个字段的取值、拼接、格式化用表达式对数组做跨行聚合、对多字段做复杂清洗、需要加密签名用 Code 节点需要读取文件、调外部 SDK、做异步操作想都别想用表达式直接上 Code 节点。比如前面说的“把多行日志聚合成特征向量”虽然用表达式能写出来但可读性很差。同样的逻辑用 Code 节点写就是几行清晰的 JavaScript。在我看来工作流的目标是先保证“人看得懂”其次才是“节点尽量少”。5.3 我习惯的脚手架先日志、后表达式、再固化最后分享一下我在团队里推的脚手架。每当我开始搭一个新的机器学习相关工作流都会在一开始先铺一层“日志 示例数据”。具体操作是把真实或者模拟的输入数据存放在一个 Set 节点里后面所有表达式都围绕这组固定数据来开发和验证。工作流跑通后再把这组示例数据抽出来作为自动化测试的输入。以后每次改动表达式先喂一遍示例数据确认输出没变再放到真实生产链路里跑。这个方法帮我挡掉了大量“改一个字段导致下游全挂”的蠢错误。再配合 n8n 的版本管理整个表达式的演进过程都有迹可循。谁改了什么、为什么改都不至于靠记忆。最后再分享一个小技巧在表达式编辑器里大多数时候你可以直接点选上游字段自动生成表达式而不需要手敲$node[...]路径。手敲容易漏掉.json这一层点选反而不会。我第一次用 n8n 时总觉得点选生成的代码又长又啰嗦后来发现那是因为它把完整路径都写清楚了反而更可靠。现在我的习惯是先点选生成再在可读性允许的范围内手动精简。说到底n8n 表达式是工作流里最不起眼却也最值得花时间熟练掌握的部分。它决定了你的工作流是“一改参数就崩”还是“换环境、切模型、调阈值都云淡风轻”。希望这篇文章里这些踩坑总结和实操写法能让你在搭机器学习自动化流程时少走几步弯路。