n8n 增量采集记不住进度：静态数据保存条件与水位设计

先定义进度代表什么 采集工作流里的 lastExecution 可以表示“上次请求时间”，也可以表示“最后成功处理记录的时间”。两者在请求成功但写入失败时会产生不同结果。建议使用能准确表达业务状态的字段名，并先定义一次部分失败是否允许推进水位。 确认静态数据的保存条件 n8n 官方将工作流静态数据标为实验性能力，要求数据量小。所核对资料说明，测试工作流时不能依靠它保存数据；工作流须发布并由触发器或 webhook 调用，成功执行后平台才检查变化并按需保存。只在编辑器连续点击运行，不能证明正式增量状态会怎样保存。 全局与节点范围不同 global 静态数据在同一工作流内共享，node 静态数据只属于设置它的节点。若读取节点和更新节点各自使用 node 范围，它们并不是在访问同一份状态。文档还说明该能力仅提供给 JavaScript Code 节点，Python Code 节点不能直接采用相同方式。 把状态写入时机与业务完成对齐 编辑建议是先读取旧水位，采集并处理数据，再根据确认成功的记录更新水位。若先写“当前时间”，后续业务写入失败却被错误分支吞下、工作流最终仍以成功结束，就可能保存过早推进的水位。整体执行失败时，不能把内存中的修改直接当成已持久化。反过来，允许重读一个小范围并按业务 ID 去重，通常更容易解释恢复过程。 具体窗口大小取决于源系统的延迟和排序方式，本文没有给出通用数值。时间相同的多条记录也应准备稳定的次级标识，避免只按时间截断。 用同一时间的两条记录检查边界 设源系统按 updated_at、id 稳定排序，旧水位是（10:00:00，101），接下来是（10:00:00，102）和（10:01:00，103）。只查询时间大于 10:00:00 会漏掉 102；应按源接口支持的方式查询“时间更晚，或时间相同且 ID 更大”，或回读重叠窗口再去重。这里的组合游标是设计示例，接口必须确实支持对应排序与过滤。 如果 102 写入失败而 103 成功，不能仅取成功记录中的最大时间就前移。应保留能覆盖失败项的进度，或把失败项可靠地登记到独立补偿队列后再推进。复跑时目标系统按业务 ID 更新，才能让重复读取不会变成重复业务记录。 JavaScript 中可用 $getWorkflowStaticData('global') 取得状态对象，再存 lastProcessedAt、lastProcessedId 这类自定义字段。它只保存你赋予的值，不会自动计算上述游标，也不提供多次重叠执行间的原子协调。 高频与并发场景另行评估 官方提示静态数据在高频执行下可能不可靠。因此不能把这个小状态对象当成具备并发协调保证的数据库。存在重叠执行时，应单独验证两个任务读写同一进度的行为，并依据业务要求选择更合适的状态存储。 文档给出的替代方式是 Data Table：先通过节点读取行，处理后再 Upsert 更新。它在测试中也保留数据，但仍需设计正确的业务更新时机。无论选哪一种存储，都应模拟写入失败、重复触发和无新数据，确认恢复后没有静默漏采。

本篇涉及的工具1

n8n

用工作流静态数据保存小型进度，或通过 Data Table 节点读写水位。

适合场景

使用 n8n 定期读取 RSS、数据库或外部增量接口的维护者。

需要留意

静态数据的成功保存条件与高频可靠性有限，不能当并发数据库。

了解项目 访问官网