错误回滚与冲突解决

回滚乐观添加（移除项目）或删除（恢复项目）都很直接。回滚更新则更复杂：您必须恢复之前的确切值。如果同一个项目被多次乐观更新，您必须分别跟踪每个之前的值，而不能只记录最初的服务器状态。

请考虑以下场景：服务器上的项目当前值为 Z。您乐观地将其更新为 X。在您的请求进行期间，另一位用户在服务器上将同一项目更新为 Y。您的请求到达后，服务器拒绝了它（发生冲突）。您的回滚目标是 Z，但服务器的当前状态是 Y。恢复 Z 会错误地覆盖 Y。

对于更新，最安全的回滚策略是在任何变更错误发生时从服务器重新获取项目，而不是恢复本地捕获的快照。这样无论其他用户同时进行了哪些更改，您显示的始终都是服务器的权威状态。重新获取速度较慢，但始终正确。

如果乐观更新因并发修改而失败，设计良好的接口会返回 HTTP 409 冲突。响应正文通常会包含服务器当前的状态。您的错误处理程序应检测 409，使用响应正文将本地状态更新为服务器当前的值，并通知用户其更改未能保存。

幂等变更无论执行多少次，都会产生相同的结果。将变更设计为幂等的（使用 PUT 而不是 POST、包含完整的资源状态、使用幂等性密钥），可以在失败时安全重试，而不必担心重复应用变更。这会显著简化回滚逻辑。

连续双击提交按钮可能会触发两次相同的变更。请使用 isSubmitting 标志来防止这种情况：变更开始时将其设为启用，完成时将其重置（无论成功还是失败）。当 isSubmitting 处于启用状态时，禁用触发元素。这样可以在用户界面层面消除重复变更。

要在服务器端去重，请在每个变更请求中加入唯一的 Idempotency-Key 请求标头。用户发起操作时，使用 crypto.randomUUID() 生成该密钥。服务器会检测重复的密钥，并返回与原始请求相同的响应，而不会再次执行该操作。

变更进行期间，您可以显示一个不显眼的指示器，表明乐观状态尚未确认：例如小型脉动圆点、“正在保存……”文字，或降低项目的不透明度。这能在不阻塞交互的情况下传达不确定性。成功时清除指示器；失败时回滚并清除指示器。

回滚逻辑中的意外错误（例如在恢复状态时访问未定义值的属性）可能会导致组件崩溃。请将变更操作较多的组件包裹在错误边界中，以便灾难性的回滚失败能够显示友好的错误界面，而不是空白屏幕。请记录这些错误的日志以便调试。

一种可靠的冲突检测策略是为每次变更附带版本号或 ETag。服务器会将客户端发送的版本与当前版本进行比较。如果两者不同（说明发生了其他更新），服务器就返回 409。这就是乐观并发控制：假设不会发生冲突，但在冲突发生时进行检测。

回滚逻辑经常未经测试，因为网络失败很难模拟。请使用模拟服务工作线程（MSW）等工具，在测试中返回错误响应。请针对以下情况编写明确的测试：409 冲突处理、网络超时回滚、双击去重，以及失败后的状态一致性。这些边界情况正是错误容易隐藏的地方。

当由于其他用户的并发修改导致乐观更新失败时，设计良好的接口会返回哪个 HTTP 状态码？

更新回滚比添加或删除更复杂——发生错误时始终重新获取数据，以避免过时快照问题。HTTP 409 冲突表示乐观并发控制失败；请使用响应正文恢复服务器当前的状态。将变更设计为幂等的，以便安全重试。使用 isSubmitting 和服务器端幂等性密钥防止重复触发。使用 MSW 模拟错误，明确测试回滚路径。