n8n Python 代码升级后报错：从 Pyodide 迁到原生执行器

把运行环境写进迁移记录 “这段是 Python”还不足以解释它为什么失败。n8n 官方把旧 Pyodide 与 Native Python 分开说明：原生支持通过 task runners 提供，从 1.111.0 引入，在 n8n 2 中稳定；n8n 2 不再支持旧 Pyodide。开始改脚本前，记录 n8n 版本、Cloud 或自托管、节点模式和失败位置，先判断是语法、变量还是运行环境的问题。 先处理数据入口 Code 节点有处理全部输入与逐项处理两种模式。原生 Python 在这两种模式下分别提供 _items 与 _item，不支持旧环境中其他 n8n 内建方法和变量。把输入集合当单条对象访问，或照搬旧快捷变量，都可能在业务计算开始前报错。 建议先用最小脚本只读取输入的一个业务字段并返回，再逐段迁移计算逻辑。不要一边换模式，一边重写聚合规则，否则很难确认条数变化来自哪里。 检查对象访问写法 原生 Python 要用字典式方括号访问，例如 item["json"]["name"]。官方说明，Pyodide 曾接受的一些点号访问方式不能直接迁移。修复时同时检查缺失键和空值，不要只把点号机械替换后便认为业务语义一致。 先用无依赖脚本确认运行器入口 在原生 Python 的 Run Once for All Items 模式，最小检查可先返回 _items，让两条带不同业务 ID 的输入原样通过；逐项模式则返回 _item，核对每条仍对应自己。通过后再读取 _item["json"]["name"] 等具体字段，不要一开始就引入数据分析库。 迁移一项姓名清理时，先规定 name 必须是字符串，再去除首尾空格。样例同时包含正常字符串、空字符串、null 和缺失键：后两者要进入你明确的缺失或错误处理，不能为了让脚本通过而无条件转成 "None"。只改点号访问不会自动解决这些语义差异。 旧脚本若使用日期快捷变量或读取其他节点的内建方法，应在前序节点把所需值显式传入，再由原生 Python 处理 _items 或 _item。这样迁移记录能说清输入从哪里来，也不会把 JavaScript 或旧 Pyodide 示例中的快捷写法误用到原生执行器。 模块不是写一行 import 就存在 自托管的原生 Python 需要运行器镜像中包含依赖，并明确允许使用。所核对文档还说明 Cloud 的 Python Code 节点不允许用户导入标准库或第三方库。迁移设计应先确认实际能力，再决定将某一步保留为代码、改为现有节点，或交给已配置的外部服务。 此处不提供放宽运行器限制的通用配置。若任务只需一个现成数据节点，使用它往往能让依赖更少；确需依赖时，则由部署维护者确认版本和允许范围。 用结果契约验收 准备正常、多条、空输入和缺失字段四类样例，比较迁移前后的业务 ID、字段类型与输出条数。若代码产生了全新数据项，还要检查下游对原记录的引用关系。成功执行只说明没有抛异常，不证明结果仍属于正确客户或订单。 保留旧版本流程和样例结果，待新环境在真实约束下通过验收后再切换。

本篇涉及的工具1

n8n

通过原生 Python task runner 处理 Code 节点输入与返回。

适合场景

准备升级 n8n，或正在排查 Python Code 节点兼容性问题的维护者。

需要留意

原生变量、字典访问和模块允许范围与旧 Pyodide 不同。

了解项目 访问官网