我改完 n8n 工作流，为什么跑的还是旧版本？
改完 n8n 工作流后仍跑旧版本，先核对修改是否已经发布，而不是先怀疑修改没保存。n8n 会在你编辑时自动保存，通常 1 到 5 秒内完成，不需要手动点保存；但生产执行使用的是已发布的版本，不是你最新的编辑。也就是说，你看到的 canvas 是最新草稿，真实触发走的可能是上一次发布的版本。
下面用一个假设场景说明判断顺序：某个节点原来输出 sales-old，你把它改成输出 sales-new。手动试跑能看到 sales-new，但一次新的生产执行仍然得到 sales-old。这时先不要改代码，先核对发布状态；SHMLANG 的建议也是先确认这一步。
手动已经是新值，先看哪里？
按这个顺序看，能少走弯路：
- 看当前工作流是否还有未发布的修改。工作流曾经发布过，不代表之后的修改已经上线。
- 看发布是否完成。发布是异步的，n8n 要在后台处理触发器的变化，按钮会显示 Publishing，直到 n8n 确认结果。刷新页面也仍然显示这个状态，因为状态存在服务器上。
- 用发布完成后的一条新事件，去找对应的生产执行，而不是翻旧记录。
如果按钮显示的是部分发布或发布失败，要分开看。部分发布时新版本已经发布，只是至少有一个触发器没激活，工作流只运行已激活的触发器；发布失败时所有触发器都没激活，工作流没有在跑。两种情况都要看界面提示，确认你依赖的那个触发器是否已激活，再决定要不要重新发布。
怎样确认这次真的用了新修改？
继续用上面的假设例子。先准备不含真实客户信息的受控测试数据，比如事件标识 eventId=version-check-001。手动试跑一次，看到 sales-new，这只说明这一次观察到的输出是新值；手动运行可能使用固定数据，不能据此证明整个草稿逻辑都对，更不能证明生产已经更新。
发布后，等界面确认发布完成，再让一条带标识的受控事件进入刚发布的这个工作流对应的触发入口，例如 eventId=version-check-002。这次验证只使用受控的测试数据与受控的下游目标，不操作真实客户或真实业务目标。然后到工作流的 Executions 里，按执行时间找到这次生产执行，在它的输入数据中核对 eventId，再查看那个修改节点的输出。
如果这条记录里是 sales-new，说明这次生产执行已经用上了新修改。如果仍然是 sales-old，再进入下一步核对，不要直接下结论。需要提醒的是，生产执行不会像手动运行那样直接显示在编辑器的画布上，你要到 Executions 标签里看；能不能看到记录，还受工作流的执行保存设置影响。
发布完了，为什么看着还是旧结果？
先确认你看的是不是真正的那条执行记录。核对三件事：执行是否属于你实际修改的那个工作流和实例，执行时间是否在发布完成之后，事件标识是否对应你刚发的那条。
这里容易混淆两种历史。工作流历史是保存下来的版本配置，可以查看并恢复旧版本；执行历史是工作流跑过的记录，展示的是对应那次运行的结果。看版本历史只能确认当时的节点和参数，看执行记录才能确认某次运行实际输出了什么，两者都不能单凭“旧”就断定输出是 sales-old。工作流历史不是执行结果，执行列表也不代表某个版本已经上线。
常见问题
恢复旧版本后，生产会跟着恢复吗？
不会自动跟着变。恢复操作是把选中的版本放回当前工作流，方便你继续编辑或对比；生产执行用的仍然是当前已发布的版本。要让它生效，需要在确认无误后重新发布。
固定数据会不会影响手动测试？
会。手动执行时可以把某个节点的输出固定住，后续运行会直接使用这份固定数据，而不是真的执行该节点。生产执行会忽略所有固定数据。所以如果手动结果看起来总是对，先检查测试是否用了固定数据，它可能掩盖了节点实际运行时的表现。
排查时不必一次就锁定所有原因。先确认发布状态，再用一条可识别的新事件核对修改节点的输出；如果这样仍见旧值，再核对实际工作流、实例和执行时间。
评论 (0)
还没有评论，来发表第一条吧。