别让请求头成为瓶颈：JS 网络通信中的隐藏细节与最佳实践

开发过程中最让人头秃的瞬间之一，莫过于接口逻辑全通，代码也没报错，可浏览器控制台突然弹出一堆红色的 CORS 错误或者 403 禁止访问。很多时候问题并不出在业务逻辑上，而是那几十个字符的请求头（Headers）没配对。

不管是原生 fetch 还是封装完善的 axios，核心都是在告诉服务器“我是谁”以及“我发的数据是什么格式”。以 fetch 为例，直接在 options 对象里塞入 headers 即可，但千万别漏掉 method 和 credentials 这些隐形开关。

fetch('/api/user', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer ' + token
  },
  body: JSON.stringify({ name: 'tom' }),
  credentials: 'include' 
})

这里有个极易忽视的细节：Content-Type 与实际 payload 必须匹配。如果你在 headers 里强制写了 application/json，body 里的数据就必须经过 JSON.stringify 处理。反之，如果后端要求接收表单数据，却不小心设置了这个类型，或者直接用普通对象做 body，前端怎么发、后端怎么收都是空的。

切换到 axios 时，配置显得更友好些。默认情况下它会自动设置 Content-Type，但如果涉及到文件上传，情况就不一样了。上传文件时通常需要 multipart/form-data，这时候建议直接使用 FormData 实例传给 body，并且不要把 Content-Type 手动写死，让浏览器自己去生成 boundary 边界符。一旦强行指定，文件流就会损坏，导致后端解析失败。

再往深了说，自定义 Header 往往是跨域问题的元凶。当你为了追踪链路加上了 X-Trace-ID 或者 Client-Version，浏览器会触发 OPTIONS 预检请求。这意味着服务器不仅要处理业务接口，还得提前声明允许你带这些字段。如果后端同事只开了通用权限，却没在 Access-Control-Allow-Headers 里放行特定字段，前端改十遍代码都是白搭。遇到这种情况，与其闷头查错，不如直接让后端同步一下允许的字段列表。

还有个关乎安全的点，是关于 Token 的放置位置。虽然放在 Authorization 字段里是最标准做法，但部分老旧系统可能只认 Cookie。如果是后者，记得在 fetch 中开启 credentials: 'include'，并在 ajax 请求中配置 withCredentials: true。同时，不要将所有敏感配置都硬编码在代码里，利用环境变量区分测试、生产环境的密钥，才是防止泄露的正道。

调试请求头其实不需要太高深的理论，打开浏览器的 Network 面板，点击具体请求查看 Request Headers 和 Response Headers，往往比猜参数更有效。关注状态码，看看预检请求是否返回了 200，确认返回头里有没有包含你需要的允许策略。

网络请求看似简单，实则全是细节。掌握这些底层规则，能帮你避开至少一半的诡异 bug。毕竟，代码跑通了只是第一步，数据稳定地抵达才是交付的关键。