Contentful 版本冲突应安全重试

Contentful 使用乐观锁保护条目。每次更新都会包含客户端认为自己正在编辑的版本号。如果另一个更改先提交，Contentful 会拒绝这个过期更新，而不是让它覆盖较新的工作。

这种冲突是一种安全机制。不应让它成为本地化流程的死胡同。

健康团队中为什么会发生冲突

一次翻译请求可能需要时间。在生成或审核期间，编辑人员可能会修正源条目，其他语言区域可能会被更新，或者自动化流程可能会更改元数据。

等到本地化后的值准备好要推送时，之前记录的条目版本已经过期了。

这并不意味着有人犯了错。这意味着发布系统的多个部分正在同时工作。

绝不要盲目重试同一个过期负载

最简单的重试方式是重复被拒绝的请求。那不可能成功，因为它携带的是同一个过期版本号。

危险的替代方案是获取最新的版本号，然后重新发送整个旧条目负载。这样也许能通过版本检查，但会覆盖自翻译开始以来已经发生更改的字段。

安全的重试需要最新状态和精确的补丁。

重新读取、合并并更新

当 Contentful 报告版本冲突时，工作流应当：

1. 从同一个 space 和 environment 中获取当前条目
2. 检查最新的字段和版本
3. 仅合并翻译请求中已批准的目标语言区域值
4. 保留无关字段和语言区域值
5. 使用最新版本提交更新

这能让重试与用户的真实意图保持一致。翻译请求想要更改的是特定的本地化字段，而不是恢复整个条目的旧快照。

决定何时不应重试

自动冲突恢复需要有限制。

如果在审核开始之后，完全相同的目标语言区域字段发生了变化，那么系统发现的就是真实的编辑冲突。自动重试可能会替换较新的人为修改。这种情况应当停止并请求人工审核。

同样，反复发生冲突可能表明存在繁忙的自动化循环，或者某个集成正在持续写入该条目。设置有界的重试次数可以防止本地化流程无限加入这个循环。

错误信息应保持可操作性：指出条目、受影响的语言区域和字段，以及发生冲突时所处的阶段。

保持源内容与目标内容的归属清晰

当工作流具有严格的写入边界时，冲突处理会更容易。翻译推送应只更改已批准的目标语言区域。它们不应写入源字段、内容类型元数据、标签或无关的语言区域值。

这种边界能降低合并复杂度，并让审计日志更有意义。当重试成功时，团队可以清楚看到究竟哪些本地化字段发生了变化，以及原因是什么。

要点总结

在协作型 CMS 中，版本冲突是正常现象。把每一次冲突都视为翻译失败，会让工作流显得脆弱；忽视冲突，则会让它变得不安全。

获取最新条目，合并最小范围内已批准的更改，并在明确限制内进行重试。当同一个字段在双方都发生了变化时，停止并交由人工审核。可靠性来自于尊重并发工作，而不是假装它不存在。