fetch() 更适合现代项目因其设计更简洁、基于 Promise 且与 Service Worker 兼容，但需手动处理 cookie、HTTP 错误和 JSON 解析；兼容性差（IE 不支持），建议用 axios 或封装回退；数据校验、加载状态管理、DOM 渲染优化和用户路径完整性是关键实践。
为什么 fetch() 比 XMLHttpRequest 更适合现代项目
默认不带 cookie、不自动解析 JSON、错误状态码（如 404/500）不会 reject——这些不是 bug，是设计选择。用 fetch() 必须手动检查 response.ok 和调用 response.json()，否则静默失败很常见。
实操建议：
- 始终用
if (!response.ok) throw new Error(response.status)拦截 HTTP 错误 - 不要省略
await response.json()，fetch()返回的是 ReadableStream，不是数据本身 - 需要携带 cookie 时，必须显式传
{ credentials: 'include' }，默认是'omit' - IE 完全不支持，若需兼容，直接上
axios或封装一层XMLHttpRequest回退逻辑
渲染前必须校验数据结构，而不是假设后端永远返回正确格式
后端字段缺失、类型错位（比如 id 是字符串却当数字用）、嵌套层级变更——这些在联调期未必暴露，上线后极易导致 Cannot read property 'xxx' of undefined。
实操建议：
- 用可选链操作符快速防御：
data?.items?.[0]?.title，但别依赖它掩盖深层问题 - 对关键字段做存在性断言：
if (!Array.isArray(data.list)) { console.error('expected array, got', typeof data.list); return; } - 复杂结构建议配合 TypeScript 类型守卫或
zod做运行时校验，尤其在 SSR 或缓存场景下 - 模板渲染时避免直接插值
${data.user.name}，先确保data.user存在，否则用空对象兜底
加载状态、错误提示和空状态不能靠“等接口返回再决定”
用户点击按钮后，界面卡住 2 秒没反馈，大概率会重复点击；列表为空时只留白，用户不知道是没数据、加载失败还是网络中断。
