AJAX 是用 XMLHttpRequest 或 fetch() 发起异步 HTTP 请求的实践方式；XMLHttpRequest 仍具调试与上传优势，fetch() 需注意默认不报错、无 Cookie、需手动处理 JSON 和超时等陷阱。
JavaScript AJAX 不是某种独立技术，而是用 XMLHttpRequest 或 fetch() 发起异步 HTTP 请求的一套实践方式——它本身没有“安装包”，也不需要“学习新语言”，关键在于理解怎么发、怎么收、怎么防错。
为什么 XMLHttpRequest 还值得看？
虽然 fetch() 更现代，但很多老项目、内部系统、甚至某些浏览器（如 IE11）仍依赖 XMLHttpRequest。它的状态机模型（readyState）和手动处理响应头的能力，在调试超时、重定向、流式响应时反而更透明。
-
XMLHttpRequest支持upload.onprogress，上传大文件时能精确监听进度；fetch()原生不支持 - 它允许同步请求（
async: false），虽已被弃用，但在极少数嵌入式脚本或 legacy 测试中仍可能遇到 - 错误捕获更细：网络失败、HTTP 状态码 4xx/5xx、解析失败可分层处理，而
fetch()默认对 404/500 不抛错
fetch() 的常见陷阱有哪些？
fetch() 看似简单，但默认行为和直觉有偏差，上线后容易出 silent failure。
- 它只在**网络异常**时 reject，
404、500仍返回Response对象，必须手动检查response.ok或response.status - 默认不带 Cookie：
credentials: 'include'必须显式设置，否则跨域登录态丢失 -
response.json()是异步的，且会 consume body，重复调用会报TypeError: already read - 超时需手动实现：
fetch()本身不支持timeout选项，得用AbortController+setTimeout
POST 请求发 JSON 数据，headers 怎么设才有效？
少设一个 header，后端就可能收不到 req.body，尤其用 Express、FastAPI、Spring Boot 时。
立即学习“Java免费学习笔记（深入）”；
- 必须设置
Content-Type: application/json，否则后端中间件（如express.json()）直接跳过解析 - 不要手动 JSON.stringify() 后再加引号——
JSON.stringify({a:1})正确，"{a:1}"错误（不是合法 JSON） - 如果后端要求带 token，记得加
Authorization: Bearer <token>，且确保 token 字符串没前后空格 - 用
fetch()时，body字段只接受string/FormData/Blob，不能传对象
示例：
fetch('/api/user', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer abc123'
},
body: JSON.stringify({ name: 'Alice', age: 30 })
})
跨域请求被拦，到底该改前端还是后端？
前端加 mode: 'cors' 或配 Access-Control-Allow-Origin header 都解决不了根本问题——CORS 是浏览器施加的安全限制，服务端必须明确许可，前端只是发起方。
- 开发阶段：用 Webpack/Vite 的
proxy配置绕过浏览器 CORS（实际走本地服务器转发），比开后端 header 更安全 - 生产环境：后端必须返回
Access-Control-Allow-Origin，值不能为*（若带 credentials）；还要注意预检请求（OPTIONS）是否被 Nginx/Apache 拦截 - 不要在前端代码里写
credentials: 'include'却让后端漏配Access-Control-Allow-Credentials: true，这会导致整个请求被静默丢弃
真正卡住人的，往往不是语法，而是某个 header 没对齐、某个预检响应没返回、或者 cookie 的 SameSite 属性和请求上下文冲突——这些细节在控制台 Network 标签页里才能看清。
