POST /api/drafts尚未发送。输入会留在这里，任何失败都不会清空它。
周报超时后，先查结果，不要再发一遍
你正在保存周报草稿。先模拟没有 HTTP 响应的超时，再用同一个 request key 查询保存结果；成功、失败和恢复都留在同一份草稿上。
DRAFT SERVICE · request key: wk-42编辑中
发布周报时客户端等了 30 秒仍没有 HTTP 响应。先触发一次超时，再查看为什么不能立刻重发同一份草稿。
第 0 步：这是一条写入请求；还没收到响应前，不能从界面猜测服务端结果。
把刚才的现象说清楚
网络错误发生在 HTTP 响应抵达前：浏览器或客户端拿不到状态码。超时也只说明客户端停止等待，不代表服务端没有写入。
离线、DNS、连接失败、超时与取消都不是 4xx/5xx；后两类是服务器已经回答。
GET / HEAD 可以有限退避；POST 保存、付款、发送等写入要先确认副作用。
失败、取消或离线不清空用户内容；让用户看到当前处于“未确认完成”。
AbortController 是用户意图：显示已取消，不自动重试，也别让旧响应覆盖新结果。
什么时候用，怎么分流
看到 fetch 失败时，第一问不是“重试吗”，而是“有没有 HTTP 响应、这次有没有副作用”。
- 先在 Network 或日志确认有没有状态码：4xx/5xx 走状态码或 server-error，不要伪装成网络错误。
- 无响应的 GET 用带抖动的有限退避（例如 1s、2s、4s，封顶 3 次）。
- 无响应的写入保留内容与 request key，查询结果；未确认前禁止重放。
- 离线等用户恢复在线后主动重试；取消只显示“已取消”。
同一周报，只改“查”还是“重发”
目标都是不丢稿。关键差异是面对未知服务端结果时是否先查询。
超时后查询 wk-42，服务端返回已保存的 #184；页面显示结果，不重放 POST。
第一次其实已保存，连续重发又创建多份草稿；付款场景会造成重复扣款。
快速自测
POST 扣款请求超时且没有任何 HTTP 状态码，下一步应是什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。