服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 官方当前写明 3.0.0 为 early access，不能据版本号推断所有 Cloud 账号已升级或正式稳定发布。
- 自托管 3.0 要求 Docker 部署，不再支持通过 npm 或 npx n8n 运行；已有 Docker Compose 部署可以继续使用。
- 所有用户都能打开迁移报告，但普通用户只看得到有编辑权限的工作流；实例问题与全量刷新由 owner／管理员处理。
- 自动迁移会保存新的工作流版本，原已发布版本继续运行，直到明确发布新版本；报告无未解决项仍不等于业务验收通过。
现在能升级，不代表每个实例都适合立即升级
截至本文核验，n8n 的 v3.0 Breaking changes 页面明确写着“early access release”。本文面向评估升级的实例负责人和工作流维护者，解释迁移准备；没有核验每种 Cloud 套餐的开放批次、地区、价格或账号实际升级状态。使用 Cloud 的团队应核对自己的实例通知，不能直接套用自托管部署要求。
先记录当前版本、部署方式和关键工作流，再打开 Settings > Migration Report。报告会列出实例内受影响的工作流和配置；不要只对照一份通用节点清单，就认定自己的实例已准备好。
报告看起来没问题？先确认你看得到全部范围
owner 和管理员可查看所有工作流问题、Instance issues，并刷新全量扫描；其他用户只看到自己有编辑权限的工作流，且看不到 Instance issues 标签页。普通维护者的空报告不能代表整个实例没有问题，应请有相应权限的负责人汇总。
按影响先处理 Upgrade blocked 和 Executions will fail，再处理可能执行失败、行为变化和能力移除。保存工作流会触发该工作流重查；Last updated 表示上次全量扫描时间。负责人完成修复后应刷新报告，同时核对工作流和实例两类问题。
自托管先改部署方式，并保住可恢复的数据
n8n 3.0 不再提供可运行的 npm 包，npm 或 npx n8n 安装需要先迁到 Docker 部署。已经用 Docker Compose 的实例可以保留这种方式；这并不免除镜像版本、配置和数据迁移检查。不要用覆盖升级来试探生产兼容性。
升级前备份数据库及相关持久化数据，并验证可恢复路径。文档还将二进制文件目录从 ~/.n8n/binaryData 改为 ~/.n8n/storage；两个目录同时存在会阻止启动，应先按官方迁移说明处理并保留备份，不能随手删目录。
使用 n8n 开发 CLI 的测试环境还要留意：不同镜像使用不同 Docker 数据卷，数据库迁移只向前。更换 CLI 或镜像前先导出需要保留的测试工作流；不要把移除旧数据卷当成通用回退办法。
自动替换节点后，为什么线上还在跑旧逻辑
报告只为支持自动改写的问题显示 Migrate，例如把 Cron 改为 Schedule Trigger。确认变更后，n8n 保存一个新版本；已经发布的工作流继续运行当前版本，直到选择 Publish。可先 Skip publishing，在开发环境检查结果。
移除的节点会导致相关工作流执行失败，相关已发布触发器也不会激活。AI Transform 被移除且不会自动迁移；若已有生成的 JavaScript，可通过迁移报告移到 Code 节点，没有生成代码则要手工替换原有处理。不要把所有旧节点都理解成可以一键升级。
用受控测试输入核对输出、分支和触发条件，再决定发布。迁移工具只处理节点变更，不保证你的业务结果仍符合预期；保存、迁移、测试通过和发布是不同状态。
节点没报错，也要检查默认行为与客户端
Always Output Data 现在只在所有输出都没有数据时才生成空项，多输出节点的下游分支可能变化。使用 Chat Trigger 的 Using Response Nodes 模式时，新 WebSocket 消息采用 JSON 帧；官方要求 @n8n/chat 至少 1.31.0，自定义客户端也要按新消息类型和心跳约定处理。
SlackTrigger 使用的 Slack API 凭据必须包含 Signing Secret，缺少时会影响发布或重启后的触发器激活。让有权限的管理员按官方说明配置，不要把签名密钥贴进工单、文章或测试样本。
还要检查压缩文件上限等实例行为：解压总量默认由 2 GiB 降为 256 MiB，条目数由 5000 降为 1000。因新限制失败时先核输入与容量需求，不能把它笼统归成网络或代理故障。
上线前确认什么，报告清零后还剩什么
完成节点与实例配置修复后，由 owner／管理员刷新报告；普通用户重新载入报告核对自己已保存的工作流。两类问题均无未解决项后，仍要对照官方破坏性变更清单，检查工具无法发现的变化，再按团队的升级安排操作。
保留升级前备份、目标版本、关键输入输出和负责人确认，检查工作流实际发布版本、定时／Webhook 触发及必要的外部客户端。若新环境异常，应使用已验证的恢复方案；不能假设旧镜像能直接读取已迁移的数据库。
本文没有执行任何实例升级、外部连接或凭据操作。代理不会恢复被移除的节点、替代 Docker 部署或改变产品资格；只有具体 DNS、TLS、代理认证或超时证据，才值得另行排查网络路径。
资料来源
常见问题
把问题标成 Won’t fix，会修复工作流吗？
不会。这只是把该条工作流发现计为已处理、不再列为 open；也可 Reopen 撤回。它不会替换节点或改变执行逻辑，不应拿来证明生产兼容。
导出的 CSV 能代表整个实例的迁移进度吗？
导出只包含当前用户可见的工作流和问题。普通用户的导出不是全实例审计；实例汇总列会在每一行重复，也不能把这些重复值相加。
通知工作流 owner 后，问题就解决了吗？
没有。管理员发通知还需要实例 SMTP 和 owner 邮箱；Notified 仍属于未解决状态。应以实际修复、重新扫描与测试结果判断。