带authorization头的跨域请求必触发options预检，需前后端协同满足三重条件：预检通过、凭证合法、错误可控；后端须移除www-authenticate头防401弹窗死循环，前端统一用bearer token且不混用credentials与authorization。
带 Authorization 头的跨域请求会触发浏览器预检（OPTIONS），且极易因配置不当导致 401 弹窗死循环或 CORS 拒绝。核心不是前端“怎么发”，而是前后端协同满足三重条件：预检通过、凭证合法、错误可控。
必须处理 OPTIONS 预检请求
只要请求含 Authorization 头，浏览器一定先发 OPTIONS 请求。服务端若未响应或响应头缺失，主请求根本不会发出。
- 对所有
OPTIONS路径返回204 No Content或200 OK，不执行业务逻辑 - 响应头必须包含：
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONSAccess-Control-Allow-Headers: Authorization, Content-TypeAccess-Control-Allow-Origin: https://your-frontend.com（不能为*）Access-Control-Allow-Credentials: true - Node.js Express 可用
cors中间件统一配置，避免手动漏写
前端 fetch 必须显式声明 credentials
Authorization 是自定义请求头，但携带凭据（如 Cookie）和 Token 是两回事。若后端依赖 Cookie 认证，前端必须开启凭据；若只用 Bearer Token，则无需 credentials: 'include'，反而更安全。
- 仅传 Token（推荐）：
headers: { 'Authorization': 'Bearer xxx' }，不设credentials字段（默认为'same-origin'） - 需同步 Cookie（如 SSO 场景）：
credentials: 'include'，且后端Access-Control-Allow-Origin必须为具体域名，不可用* - 切勿混用：既设
credentials: 'include'又在 header 里手动加Authorization，易引发 401 弹窗
规避 401 弹窗死循环
浏览器对带凭据的 401 响应 + WWW-Authenticate 头会强制弹出认证框，JavaScript 无法拦截。这是最常被忽视的陷阱。
- 后端务必移除所有接口的
WWW-Authenticate响应头——它只适用于 Basic/Digest 认证，与 JWT/Token 机制冲突 - 前端统一用
Authorization: Bearer xxx，服务端验证失败时返回401+ 纯 JSON 错误体（如{ "error": "token_expired" }），不附带任何认证相关头 - fetch 中检查
response.status === 401后主动登出或跳转，而不是依赖网络层错误捕获
调试时的关键验证点
遇到失败，不要只看控制台报错，直接查 Network 面板中请求的「Headers」和「Response」标签页：
- 预检（OPTIONS）响应头是否有
Access-Control-Allow-Headers: Authorization - 主请求响应头是否含
Access-Control-Allow-Origin且值匹配当前页面源 - 主请求响应状态是
401但响应体为空？说明被 CORS 阻断，不是后端没返回，而是浏览器没放行 - 看到弹窗？立刻检查响应头是否误带
WWW-Authenticate，并确认前端没同时发 Cookie 和 Token
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
