17370845950

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 不抛错

f

etch() 的常见陷阱有哪些？

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 时。

• 必须设置 Content-Type: application/json，否则后端中间件（如 express.json()）直接跳过解析
• 不要手动 JSON.stringify() 后再加引号——JSON.stringify({a:1}) 正确，"{a:1}" 错误（不是合法 JSON）
• 如果后端要求带 token，记得加 Authorization: Bearer ，且确保 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 标签页里才能看清。