JavaScript 网络请求首选 fetch，但需手动处理错误（如检查 response.ok 或 status）、正确设置 POST 的 Content-Type 与 body、显式配置 credentials 支持 cookie 或 JWT，并注意 IE 兼容性及请求生命周期控制。
JavaScript 做网络请求，首选 fetch；它原生支持、语法简洁、返回 Promise，比老旧的 XMLHttpRequest 更可靠。但直接用 fetch 有坑，尤其错误处理和跨域场景，得手动补全逻辑。
fetch 不会自动抛出 HTTP 错误状态（如 404/500）
fetch 只在网络失败（如断网、DNS 失败）时 reject，而 HTTP 状态码 404、500、401 等仍算“成功”，response.ok 为 false，但 Promise 并不中断。不检查就直接 await response.json()，容易掩盖服务端报错。
- 务必在
await fetch(...)后加if (!response.ok) throw new Error(...) - 或统一封装：判断
response.status >= 400时主动throw -
response.headers.get('content-type')可提前判断是否能安全调用.json()，避免解析空响应或 HTML 错误页时报错
POST 请求必须手动设置 Content-Type 和 body 格式
默认 fetch 不带任何 header，且 body 必须是字符串、FormData 或 Blob，不能直接传对象。
- 发 JSON：设
headers: { 'Content-Type': 'application/json' }，并用JSON.stringify(data)转换body - 发表单数据：用
new FormData()，不用设Content-Type（浏览器会自动生成带 boundary 的 multipart 类型） - 发 URL 编码表单：
new URLSearchParams(data).toString()，再配'application/x-www-form-urlencoded'
需要 cookie 或认证凭据时，credentials 不能省
默认 fetch 不发送 cookie，即使同域；跨域请求更需显式声明。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- 同域带 cookie：加
credentials: 'include' - 跨域且后端允许凭据：后端响应头必须含
Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能为*（得写具体域名） - JWT 场景常用
Authorizationheader：headers: { Authorization: 'Bearer ' + token }
旧浏览器兼容性差，IE 完全不支持 fetch
若需支持 IE11 或更低版本，不能只靠 polyfill —— whatwg-fetch 能补基础功能，但不支持 AbortController（取消请求）、keepalive 等现代特性。
- 简单兼容：引入
whatwg-fetch，再用Promise.finally()替代finally方法（IE 无） - 复杂需求（如上传进度、超时控制、取消）建议改用
axios，它内部已处理这些边界 - 注意：Vite/Webpack 默认不 polyfill，需在入口或
polyfills.js中显式 import
真正麻烦的不是怎么发请求，而是怎么让一次请求在各种失败路径下都可预测地结束——比如用户切页时未完成的请求还在解析响应，或者连续点击触发重复提交。这些得靠 AbortController、防抖、loading 状态隔离来兜底，而不是寄希望于 fetch 自己扛住。
