fetch 交互需先检查 response.ok 再 await response.json()，否则易解析错误页或空响应；须校验数据结构、深拷贝防篡改、区分错误类型并提供 fallback。
JavaScript 与 API 交互的核心是 fetch，但“能发请求”不等于“处理 JSON 安全可靠”——常见错误不是收不到数据，而是没检查 response.ok、没处理 response.status、或直接 .json() 后忽略 Promise 拒绝。
用 fetch 发请求前必须检查 response.ok
fetch 只在网络失败时 reject（比如断网、DNS 错误），而 HTTP 404、500、401 等 状态码 仍会 resolve。若跳过 response.ok 判断，后续 .json() 会尝试解析空响应体或 HTML 错误页，抛出 Unexpected token 这类误导性错误。
实操建议：
- 始终在
await response.json()前加if (!response.ok) throw new Error(`${response.status} ${response.statusText}`) - 不要只靠
try/catch捕获.json()，它解决不了语义错误（比如 后端 返回{error: "not found"}却状态码是 200） - 对关键业务接口，额外校验响应体结构，例如
if (typeof data !== 'object' || data === null || !('id' in data)) throw new TypeError('Invalid user object')
async/await 下正确链式处理 JSON 响应
把 .json() 当作独立异步步骤，而不是跟在 fetch() 后面无脑 .then()。否则容易写出嵌套 Promise 或忘记 await。
立即学习“Java 免费学习笔记（深入）”；
async function getUser(id) {const response = await fetch(`/api/users/${id}`); if (!response.ok) throw new Error(`HTTP ${response.status}`); const data = await response.json(); // ← 必须 await，.json() 返回 Promise if (!data?.name) throw new TypeError('User name missing'); return data; }常见错误写法：
-
const data = response.json();（没 await，data是 Promise 对象） -
return fetch(……).then(r => r.json())（外层函数没声明 async，返回的是 Promise 而非数据） - 在
.catch()里吞掉所有错误却不 re-throw 或转为业务错误类型
避免重复解析或意外修改原始 JSON 数据
从 response.json() 得到的对象是可变的普通 JS 对象。如果后续代码不小心修改了它（比如 user.name = 'test'），会影响其他引用该对象的逻辑，尤其在 React/Vue 的响应式系统中可能引发难以追踪的副作用。
实操建议：
- 需要修改时，用
structuredClone(data)（现代 浏览器 支持）或JSON.parse(JSON.stringify(data))（兼容旧环境，但不支持函数、undefined、Date 等）做深拷贝 - 对只读场景，用
Object.freeze(data)防止意外赋值（注意：只冻结第一层） - 不要把
response.json()结果直接传给第三方库（如某些图表库）而不确认其是否修改入参
错误边界和 fallback 数据要明确区分网络错误、HTTP 错误、解析错误
用户看到“加载失败”，你得知道到底是 DNS 解析失败（TypeError: Failed to fetch）、后端挂了（503 Service Unavailable），还是返回了非法 JSON（SyntaxError: Unexpected token）。每种错误的恢复策略不同。
实操建议：
- 用
instanceof区分错误类型：err instanceof TypeError（网络层）vserr.message.includes('HTTP')（业务层） - 对 401/403，触发登录态刷新；对 429，加退避重试；对 5xx，显示“服务暂时不可用”并禁用重试按钮
- 提供有意义的 fallback：空数组、默认对象，而不是
null或undefined，避免下游组件反复做空值检查
真正难的不是调通接口，而是让每次 fetch 都带着明确的契约意识：我期望什么状态？接受什么数据形状？遇到哪些错误必须中断流程？这些判断点一旦漏掉一个，就可能让 bug 潜伏数周才暴露。
