通用面试：HTTP 428 Precondition Required 如何避免丢失更新？

题干与适用场景

两个客户端同时编辑同一份文档。服务端要求更新请求携带条件首部：缺少条件时返回 428，条件存在但不再匹配时返回 412。请说明 ETag、If-Match、缓存和重试如何配合，避免后写入覆盖先写入。

面试官考察点

是否理解 428 是“必须带条件”的策略要求，412 是条件已评估但失败。
能否用强 ETag 和 If-Match 建立乐观并发控制。
能否设计读取、编辑、提交、冲突展示和重新合并流程。
能否处理缓存、幂等性、审计和异常重试边界。

回答前需要澄清的问题

哪些资源和写方法必须条件化，是否允许 If-Match: *？
ETag 是强验证器还是弱验证器，是否随每次表示变化？
客户端遇到 428、412、404 或 409 时分别怎么处理？
冲突需要字段级合并、人工选择还是直接放弃？
是否有缓存、版本号、幂等键和审计要求？

30 秒回答框架

客户端先 GET 资源并保存 ETag，编辑后用 If-Match 提交。缺少条件时服务端返回 428，表示客户端必须补条件；条件不匹配时返回 412，表示资源已被修改。客户端应重新读取、展示差异并合并后再提交，不能盲目覆盖。服务端用强 ETag 原子比较并记录版本和审计，缓存必须正确处理条件请求。

分步骤深入解答

第一步：区分 428 与 412

428 来自服务端策略：请求没有所需的前置条件；412 表示请求带了条件，但当前资源状态不满足该条件。两者都不是让客户端直接重试原请求的信号。

第二步：生成资源版本

服务端为表示生成强 ETag，内容或受保护的版本变化时更新它。GET 响应返回 ETag，客户端把它保存为编辑基线，而不是只保存本地时间戳。

第三步：提交 If-Match

客户端在 PUT、PATCH 或其他有副作用的更新中发送 If-Match。服务端在应用写入前原子比较当前 ETag；匹配才执行，否则返回 412 并保持资源不变。

http

GET /documents/42
ETag: "v17"

PUT /documents/42
If-Match: "v17"

第四步：处理冲突

收到 412 后重新 GET，向用户展示服务器版本与本地改动的差异。字段可安全合并时生成新版本；无法自动合并时要求用户选择，不能把旧的 If-Match 再发一次。

第五步：设计缓存行为

条件 GET 可以用 If-None-Match 获得 304，但写入保护使用 If-Match。缓存层不能把旧 ETag 当成当前版本，也不能缓存会泄露资源状态的错误响应。

第六步：处理异常与重试

网络超时后不要直接重放非幂等写入；先查询资源版本或使用幂等键确认结果。428 需要补条件，412 需要重新读取和合并，重试逻辑必须区分这两类动作。

第七步：记录与验证

记录版本、ETag、冲突次数、自动合并率和人工放弃率。用并发更新测试验证“先到者成功、后到者 412”，并确认审计记录能还原每次版本变化。

高质量示范回答

我会让 GET 返回强 ETag，例如 "v17"，客户端编辑时保留它。PUT 没有 If-Match 就返回 428，明确提示必须使用条件更新；带有旧 ETag 则在原子比较失败时返回 412。客户端收到 412 后重新 GET，展示服务器与本地差异，合并后用新 ETag 再提交，绝不重复发送旧条件。缓存把 If-None-Match/304 用于读取优化，不能替代写保护。超时的写请求先查询版本或用幂等键确认结果，并监控冲突率和自动合并率。

常见错误

把 428 和 412 都当成服务暂时不可用并无限重试。
使用客户端时间戳代替强 ETag 的原子比较。
收到 412 后直接覆盖服务器版本。
混淆 If-None-Match 的缓存验证与 If-Match 的写入保护。
超时后无条件重放有副作用的写请求。

追问及应对

追问一：为什么不用 Last-Modified？

时间戳精度和时钟问题可能让两个版本看起来相同；强 ETag 直接绑定表示版本，更适合防止丢失更新。

追问二：If-Match: * 什么时候有用？

它表达“资源必须存在”或避免在未知版本上创建/覆盖，具体语义要由 API 文档规定；不能把它当成无条件写入。

追问三：412 与 409 有什么区别？

412 是 HTTP 条件首部未满足；409 表示请求与当前资源状态发生业务冲突。接口可以同时使用，但响应应说明可恢复动作。

追问四：如何做字段级合并？

读取共同基线、服务器版本和本地版本，按字段策略合并；对同一字段的冲突交给用户，并用新 ETag 重新提交。

追问五：缓存返回旧 ETag 怎么办？

对编辑前的 GET 使用适当的缓存控制或 revalidation，提交失败时强制读取源站；服务端仍以当前版本原子比较为准。

追问六：怎样测试并发安全？

让两个客户端读取同一 ETag 并同时写入，验证只有一个成功、另一个收到 412；再覆盖重试、超时、缓存和审计链路。