工具笔记
让 AI 修 Fetch 保存逻辑：收到 404 不能弹成功
分别处理 HTTP 状态、网络失败和响应格式。
资料核验2026.11.12 · HTTP 与 Fetch · 浏览器及服务端请求
保存接口回了 404，界面却弹出「已保存」。如果代码只在 catch 里处理失败，这种问题很常见。Fetch 的 Promise 可以在收到非成功 HTTP 状态时正常兑现。
交给编码助手的任务
请助手从保存入口追到成功提示，列出网络异常、非成功状态和正文解析失败三条路径。给它四个本地服务响应：正常 JSON、404、204、以及 200 但正文损坏。要求成功提示只由真实产品完成条件触发。
给三种失败各留一条路径
取得响应后先判断 response.ok，再按契约读取正文。网络中断没有正常响应。返回 200 但内容不是约定的 JSON，也要按格式错误处理。遇到合法 204 时按无正文处理，别强行解析 JSON。
用 404、断开连接和 200 空正文三组样例验证。界面不必把底层细节都显示出来，但日志至少能区分状态码和解析错误。
最后重跑正常保存，成功提示应只在产品约定的完成条件成立后出现。
先准备一个对照样例
四份响应可以是 200 {"id":42}、404、204 和 200 {broken。在本地同一个保存入口依次返回它们，分别记录提示与是否重置输入。成功响应没有正文时，测试还要确认没有无条件调用 JSON 解析。
用这些结果验收
- 404 显示失败。
- 合法 204 按无正文处理。
- JSON 解析失败不会被当成成功。
- 断开连接时可重试并保留用户输入。
审查时容易漏掉什么
检查 catch 是否吞掉了失败后仍走成功分支。日志保留状态码与错误类别，界面给用户可执行的信息。对接口支持的成功状态按契约判断，不能一律要求 JSON。
为 204 明确业务是否把它视为完成，并与 200 JSON 成功分别验收。错误处理不宜用一个「请求失败」把所有状态都吞掉，至少诊断时能区分响应状态和解析错误。这样上游改契约时不必从界面猜。
