用增量令牌同步变化

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你已有一份候选人索引，想定期同步变化。教学接口约定：完整初始快照完成后得到令牌 t1；增量响应包含按稳定 id 的 upsert/delete 事件和最终 next_sync_token。字段与短 id 仅为教学约定，不是 Ashby 或 SharePoint 的真实调用格式。

具体做法

先完成初始快照并保存服务发出的令牌。下一轮原样传入旧令牌，按真实接口的分页和事件类型处理变化；新增/修改更新对应 id，删除只依据明确删除事件。全部变化成功应用后，才推进到最终新令牌。处理中失败保留原检查点，恢复需能按 id 安全重放。令牌失效时按服务文档重新建立完整快照。

反例

每天下载一页候选人，用新响应覆盖整个索引。当天没返回的 id 都删除，即使还没读完分页也先保存最新令牌。

改进写法

按上述教学增量契约同步。当前令牌 t1；变化为 upsert c1、delete c2，最终 next_sync_token=t2。原样使用 t1，处理服务规定的全部分页；按 id 应用事件，不能把本页未出现的记录当删除。全部应用成功才保存 t2；应用失败保留 t1，并说明已处理范围与重放方式。令牌失效时遵守服务的快照恢复契约，不自己编造令牌。

为什么这样改

普通列表的缺席可能来自分页、权限或过滤，不足以证明删除。变更协议提供了明确事件和续接边界；把令牌更新放在成功应用之后，可以避免检查点跳过尚未处理的变化。

如何验证

给定本地 c1、c2、c3，教学事件应更新 c1、删除 c2、保留 c3；全部成功后检查点为 t2。让 c1 应用失败时，应保留 t1并报告失败，不能仅因已收到 t2 就保存它。

核对分页完成证据、每个事件 id 和检查点更新顺序。此结果为教学推演，未调用真实候选人服务。

适用边界

服务令牌含义、分页、删除和有效期各不相同，以对应文档为准；没有增量能力时不能照用本例。需要考虑事务或可重放更新，重复读取不应造成重复对象。来源支持服务令牌复用，本例字段与恢复策略明确是教学约定。