fetch()是当前推荐的HTTP请求方式，基于Promise、语义清晰；需手动检查res.ok、显式解析响应体；credentials默认omit，跨域需配对设置include与CORS头；网络层错误如Failed to fetch多因URL错误、服务未启或拦截。
JavaScript 发送 HTTP 请求不依赖“AJAX”这个名词本身，而是靠 XMLHttpRequest 或更现代的 fetch() —— 后者已是当前推荐方式，前者仅需兼容 IE11 及更旧环境时才考虑。
用 fetch() 发起 GET/POST 请求最简写法
fetch() 是基于 Promise 的原生 API，语义清晰、链式自然。它默认只带基本请求头，不发 Cookie，且 4xx/5xx 状态码不会自动 reject（这点常被忽略）：
- GET 请求：
fetch('/api/users')即可，参数拼在 URL 后 - POST 提交 JSON：
fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ user: 'a', pass: 'b' }) }) - 必须手动检查响应状态：
if (!res.ok) throw new Error(res.status)，否则 404、500 会静默进入.then() - 响应体需显式解析：
res.json()、res.text()、res.blob()，不能直接当对象用
XMLHttpRequest 还有必要学吗？
除非维护老项目或需精细控制上传进度、取消请求（IE10+）、或处理流式响应（如长轮询），否则不建议新代码使用。它的回调风格和状态机逻辑（readyState）容易出错：
- 必须监听
onload而非onreadystatechange，否则可能漏掉成功响应 - 设置请求头要在
open()之后、send()之前，顺序错则无效 - 发送 FormData 时不要设
Content-Type，浏览器会自动生成带 boundary 的 multipart 头 - 超时需手动设
xhr.timeout = 5000并监听ontimeout，否则永不结束
为什么 fetch() 不带 Cookie？如何带上？
出于安全默认策略，fetch() 的 credentials 选项默认是 'omit'，跨域时不发 Cookie，同域也不发（与浏览器地址栏直接访问行为不一致）：
立即学习“Java免费学习笔记（深入）”；
- 要发 Cookie（含 session），必须显式传
{ credentials: 'include' } - 若后端用 CORS，还需确保响应头包含
Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能为*（必须是具体域名） - 开发时若本地前端端口（如
http://localhost:3000）调后端（如http://localhost:8000），属于跨域，credentials必须配对生效
常见错误：TypeError: Failed to fetch / NetworkError when attempting to fetch resource
这类报错不是 HTTP 状态码问题，而是网络层失败，通常意味着请求根本没发出或被拦截：
- URL 协议/主机名错误（比如写了
http://但服务跑在https://，或域名拼错） - 后端服务未启动、端口被占、防火墙拦截
- 浏览器扩展（如广告屏蔽器、隐私插件）主动阻止了该请求
- Service Worker 拦截了请求但没正确返回响应（检查
navigator.serviceWorker.ready和 DevTools 的 Application → Service Workers） - CORS 预检（OPTIONS）失败时，浏览器控制台可能只显示“Failed to fetch”，需看 Network 标签页确认是否卡在 OPTIONS 上
真正麻烦的从来不是“怎么发”，而是“发完怎么稳稳收回来”——状态判断、错误分类、重试边界、取消机制、凭证管理，这些细节堆起来才是实际工程里的分水岭。
