n8n 双工作流成功却丢数据的原因

两个 n8n 工作流都显示执行成功，客户资料却丢了一部分更新。作者记录的这次生产故障，问题出在两个工作流都把自己读到的整条记录写了回去，后写入的旧数据覆盖了先完成的修改。

这篇文章给出的办法很具体：只提交自己负责的字段，把版本校验放进更新语句，冲突后重新读取再重试。对用 n8n 串联 LLM、Webhook 和业务数据库的团队，它提醒了一件事：执行成功，不等于业务状态正确。

没有同时写入，为什么也会丢数据

作者遇到的场景是：计费 Webhook 更新客户套餐，表单提交更新联系方式。最终套餐变更保住了，联系方式却消失了，两边日志都没有报告损失。

问题藏在「读取、修改、写回」的间隔里。假设两个工作流都读到了旧记录，表单工作流先保存新联系方式，计费工作流随后把包含旧联系方式的整条记录写回，表单的修改就被覆盖了。

两个工作流不需要在同一秒写入。只要一个工作流读取之后、写回之前，另一个工作流完成了修改，就可能发生竞态条件（race condition）。

单次执行成功，只能说明写入没有报错，不能证明它保留了其他工作流的修改。

作者反对整条记录写回，也是这个原因：工作流通常只知道某个字段在某一刻的状态，并没有掌握整条记录的最新状态。

版本校验必须和写入一起完成

作者建议把「替换记录」改成「提交变更」：把指定字段改成指定值，并要求记录版本仍然等于读取时的版本。这属于乐观并发控制，即允许并发操作，提交时再检查数据是否已经被别人修改。

关键在于校验的位置。

如果先用一个 n8n 节点检查版本，再由下一个节点执行更新，两个节点之间仍有空隙，其他工作流依然可以插入修改。作者要求将版本条件直接放进同一条更新语句，并检查受影响的行数。

更新了零行，就说明当前版本已经不符合预期。工作流应该重新读取最新记录，在新状态上重新应用自己的变更，再尝试提交。如果两项修改无法同时成立，就交给人工处理。

这里的失败反而有价值：它把原本会悄悄发生的数据覆盖，变成了可以处理的冲突。

原文没有提供数据库类型、SQL 或 n8n 节点配置，也没有交代版本如何递增。落地时需要补齐这些细节，不能只加一个版本字段就认为已经解决问题。

重试要更新依据，写入要限制范围

捕获冲突之后，重试方式决定了保护是否完整。

作者区分了两种情况：从起点重新执行，能够重新读取记录；只重试写入节点，则可能继续使用内存里的旧版本和旧值。后者没有解决冲突，只是在重复提交同一份过期请求。

每次冲突重试，都要从新读取的数据出发，重新计算这次应该提交的变更。

另一个约束是字段归属。计费工作流只写套餐，不能因为读到了联系方式就把它一起写回；表单工作流只写联系方式，即使表单提到了套餐，也不能顺带修改套餐。

这两层保护作用不同：限制字段范围，可以减少误覆盖；版本校验，可以拦住基于过期状态的提交。两者一起用，才更接近作者强调的原则：工作流知道多少，就只写多少。

我的判断

作者对故障机制的解释成立，尤其是「检查和更新之间仍然存在竞态」这一点，很容易在可视化工作流里被忽略。节点排成一条线，只保证当前流程内部的顺序，无法约束另一个执行实例。

但这仍是一份生产经验记录。作者说这些故障是亲眼见过的，却没有提供日志、复现代码或改造前后的对照数据，因此不能据此判断方案带来了多大的可靠性提升。

方案也有边界。如果所有调用方都严格只更新各自独立的字段，局部更新就能避免文中的整行覆盖；当更新依赖读取结果，或多个工作流会修改同一字段时，版本校验才更关键。锁、事务和按客户串行处理也是替代做法，原文没有比较它们的成本。

还有一处表述需要收紧：整行版本不匹配，只能证明记录被改过，不能单靠它定位「哪两个变更争抢了哪个字段」。定位仍需要变更日志。若版本严格递增且条件始终保留，旧请求应持续失败；原文所说旧重试后来又成功覆盖的情况，还缺少具体实现前提。

能拿来做什么

• 检查 n8n 中更新客户资料的节点，找出「读取整条记录，再整条写回」的路径，改为明确列出允许修改的字段。
• 在 Node 数据接口中，将版本条件与字段更新放进同一次数据库操作，并让调用方能够区分版本冲突和普通执行错误。
• 检查工作流的重试入口，确保版本冲突后会重新读取、重新计算变更；同时核对前置节点是否存在不能重复执行的副作用。
• 为计费、表单和 AI 工作流分别列出可写字段，并记录更新前后的版本与字段变更，便于排查「显示成功但数据不对」的问题。