跨域请求携带凭据需前后端严格协同：前端必须设 credentials: 'include'，后端响应头须同时包含 Access-Control-Allow-Credentials: true 和具体 Access-Control-Allow-Origin（不可为 *），且预检请求（OPTIONS）也需同等配置。
跨域请求中带凭据（如 Cookie、Authorization 头）不是前端“加个参数”就能通的，而是前后端必须严格协同：前端明确声明要传，后端必须精准响应允许，缺一不可。
前端必须设置 credentials 并匹配后端规则
使用 fetch 时，若需携带 Cookie 或认证信息，必须显式指定 credentials 选项：
-
credentials: 'include'—— 总是发送凭据（即使跨域目标没设 cookie，也发空凭证）；此时后端Access-Control-Allow-Origin必须是具体域名，不能为* -
credentials: 'same-origin'—— 同源时发，跨域时不发（默认行为） -
credentials: 'omit'—— 从不发送凭据（等同于不设该字段）
注意：withCredentials = true（XMLHttpRequest）和 credentials: 'include'（fetch）效果一致，但后者是现代标准写法。
后端响应头必须成对生效
只要前端用了 credentials: 'include'，后端就必须返回以下两个响应头，且值必须严格匹配：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
Access-Control-Allow-Credentials: true—— 唯一合法值是字符串"true"，不能是1、True或布尔值 -
Access-Control-Allow-Origin: https://your-frontend.com—— 必须是完整协议+域名+端口（如https://app.example.com:3000），不可用通配符*
如果 Origin 是动态的（如多个子域名），后端需读取请求头中的 Origin 字段，白名单校验后原样回写（例如 Origin: https://shop.example.com → 回写 Access-Control-Allow-Origin: https://shop.example.com）。
预检请求（OPTIONS）不能被忽略
带凭据的非简单请求（如 POST + Content-Type: application/json 或含 Authorization 头）会触发预检。此时后端不仅要处理主请求，还必须正确响应 OPTIONS 请求：
- 对所有 OPTIONS 请求返回
204 No Content或200 OK - 在 OPTIONS 响应中同样带上
Access-Control-Allow-Credentials: true和具体Access-Control-Allow-Origin - 补全其他必要头：
Access-Control-Allow-Methods、Access-Control-Allow-Headers
常见错误：只给主接口配了 CORS 头，却没处理 OPTIONS 路由，导致预检失败，主请求根本不会发出。
调试关键点：看 Network 面板里的两个响应
打开浏览器开发者工具，在 Network 标签页中确认：
- OPTIONS 请求的响应头是否包含
Access-Control-Allow-Credentials: true和正确的Origin - 主请求（如 POST）的响应头是否也包含完全一致的这两个头
- 主请求的
Response标签为空、Status显示0，基本可判定是 CORS 拦截而非网络错误
不要依赖 catch 捕获 CORS 错误——它不会进 catch，而是直接 reject 并在控制台报错；真正能捕获的是网络超时、服务器 5xx 等非 CORS 类失败。
