fetch 无原生请求头拦截机制，需封装 request 函数统一合并动态 header（如 token、签名），结合 abortcontroller 避免竞态，并慎用 service worker 注入非敏感字段，同时规避禁止字段与 cors 陷阱。
Fetch 本身不提供请求头拦截机制，无法像 Axios 那样通过拦截器统一修改请求头。要处理复杂请求头（如动态 token、签名、多环境 Host 切换等），核心思路是封装 fetch 调用、集中管理 headers，并在发起前动态生成或注入。
手动封装 fetch 函数统一注入请求头
这是最常用也最可控的方式：写一个自定义的 request 函数，在其中预设基础 header，再根据参数或上下文动态补充。
- 基础 header（如 Content-Type、Accept）可默认设置
- 认证信息（如 Bearer Token）从 localStorage 或 auth store 中读取并注入
- 需要签名的请求，可在函数内调用签名逻辑，把结果作为 header 字段加入
- 示例：注意不能覆盖用户传入的 headers，而是合并而非替换
使用 AbortController 控制请求生命周期（配合 header 动态更新）
虽然 AbortController 不直接处理 header，但它让请求具备可取消性，适合在 header 依赖异步数据（如 token 刷新）时避免竞态问题。
- 比如 token 过期时触发刷新，新 token 返回前挂起请求，拿到后再重发 —— 此时新请求头已含最新 token
- 可用 Promise + async/await 封装 token 获取逻辑，确保 header 构建在 token 可用之后
- 避免在 headers 中硬编码过期 token，而是每次请求前实时获取
利用 Service Worker 拦截并改写 fetch 请求（高级场景）
Service Worker 可在浏览器底层拦截所有 fetch 请求，实现真正意义上的“全局 header 注入”，但有较多限制：
- 仅适用于 HTTPS 环境（localhost 除外）
- 无法修改跨域请求的敏感 header（如 Cookie、Authorization），会被浏览器自动过滤
- 适合添加非敏感字段（如 X-Client-Version、X-Request-ID）或统一打点 header
- 需在 SW 中监听 fetch 事件，用 request.clone() 获取原始请求，构造新 Request 并追加 headers
避免常见陷阱
复杂 header 处理容易出错，尤其在跨域和鉴权场景下：
- 不要在 headers 中直接写 ‘Content-Length’ 或 ‘Connection’ 等禁止手动设置的字段，浏览器会忽略或报错
- 带 credentials 的请求（如 include）若服务端未配置 CORS 允许 credentials，会导致 header 被静默丢弃
- 动态 header 如时间戳、随机 nonce，务必确保生成逻辑稳定且无副作用（比如重复调用导致 nonce 冲突）
- 调试时用浏览器 Network 面板检查 “Request Headers” 实际发出的内容，而不是只看代码里写了什么
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
