POST /api/drafts 超时后，客户端用同一个幂等键 GET 查询保存结果：服务端已写入就显示「已保存」，没写入再由用户确认后重发。
用户不会丢稿，也不会出现两份草稿；网络波动不会变成重复数据。
数据与服务 · 网络与接口
网络错误Network Error
网络错误是请求在 HTTP 响应抵达前结束的客户端状态——离线、DNS、连接失败、超时或用户取消，都没有状态码。保留输入，再按请求副作用决定是否有限重试；它不等于服务器返回的 4xx/5xx，也不自动代表写入没有发生。
客户端恢复决策台：没有 HTTP 响应时怎么办
你当客户端。请求发出去了，但没收到任何 HTTP 响应——离线、DNS、连接失败、超时或用户取消。先辨认信号，再按请求副作用选恢复动作；选对，工单盖上对应结果，退避米尺可推进。
客户端看到的失败信号
正在发送的请求
POST
/api/drafts客户端停止等待，服务端是否处理未知。保存周报，写入可能已经发生。
选完失败信号和请求，再选一个恢复动作；原因、下一步、对照会写在工单和这里。
键盘：聚焦失败信号后用 ←/→、Home、End 切换；Tab 到达请求、恢复动作、运行按钮与输入框。
网络错误一句话：请求没到或没回，和 4xx/5xx 不是一类
网络错误发生在 HTTP 响应抵达之前，客户端拿不到状态码；它和服务器已经回答的 4xx/5xx 处理方式完全不同。
失败信号卡在哪一层是否有 HTTP 响应客户端下一步
离线本机没有可用网络否，请求没出去保留输入，等在线后由用户重试
DNS 失败主机名无法解析否，没到主机读可退避重试；写查幂等，不伪造 404/500
连接失败TCP / TLS 握手未完成否，响应头未到达读可退避重试；写先确认副作用再决定
超时客户端停止等待否，等不到响应写入可能已发生，禁止盲目重放
用户取消AbortController 终止否，这是用户意图显示已取消，不自动重试
4xx / 5xx服务器已经处理是，有状态码和 body交给状态码 / server-error 流程
离开后记住
- 网络错误 = 没有 HTTP 响应；不要虚构 404 或 500，处理方式不能混在一起。
- 超时只说明客户端停止等待，不说明服务端没有写入；未知副作用的请求禁止盲目重放。
- 只有 GET / HEAD 等安全读取才用有限退避重试；写入靠幂等键或结果查询恢复。
- 用户取消是意图不是故障，显示「已取消」即可，别让旧响应覆盖新结果。
什么时候用：看到「没响应」就要分流
先确认有没有 HTTP 响应，再决定走网络错误恢复还是状态码流程；两者的重试策略相反。
- 先看有没有状态码拿到 4xx/5xx 说明请求已抵达服务器，交给状态码或 server-error 流程；没有任何响应才走网络错误恢复。
- 读和写分开GET / HEAD 这类安全读取失败可以有限重试；POST 保存、付款、发送等有副作用的请求，超时或断连后必须先确认是否已写入。
- 离线和取消不要自动重试离线期间重发不会到达；用户取消是意图，自动重试会违背用户意愿并制造竞态。
- 边界：别把服务端故障包装成网络错误5xx 是服务器在回答，容量、依赖、发布与回滚属于 server-error 的运维处置；网关把 5xx 改写成「网络错误」会让监控和重试逻辑一起失效。
怎么用：保留输入、有限退避、幂等恢复
从失败到可恢复判断的最短路径，是把用户内容、等待节奏和未知副作用放在同一张决策表里。
- 保留用户输入失败、超时或取消都不清空表单；离线期间允许继续编辑，恢复后由用户确认提交。
- 分流读 / 写安全读取走有限退避；写入先暂停，标记「未确认完成」。
- 读取用指数退避 + 抖动例如 1s、2s、4s，限制总次数（如 3 次）与总时长；仍失败给缓存或手动重试入口。
- 写入用幂等键为每次提交生成幂等键，失败或超时后用它查询结果；未确认前禁止重放，避免重复保存或扣款。
- 取消单独处理AbortController 触发后只显示「已取消」，不让旧响应覆盖新关键词的结果。
正反例：POST 保存超时，查幂等 vs 盲目重放
同一个「不丢稿、又不重复保存」的目标，只改一个关键选择——查幂等键还是立刻重发。
超时后客户端立刻把同一个 POST 重发 5 次。服务端其实第一次已经保存成功，后续重放又生成了 4 份重复草稿；扣款场景下会扣多次。
用户以为「多试几次更稳」，结果是把客户端的「不知道」直接变成了服务端的重复写入。
快速自测
POST /api/payments 扣款请求发出后客户端超时，没有任何 HTTP 响应。最安全的动作是什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。