核心是确认credentials选项、响应头、Cookie属性三者协同一致：fetch需设credentials:'include'，axios设withCredentials:true；后端必须返回Access-Control-Allow-Origin（非'*'）和Access-Control-Allow-Credentials:true；Cookie须含Secure且SameSite=None。
排查携带 Cookie 跨域时凭据配置错误，核心是确认 credentials 选项、响应头、Cookie 属性三者是否协同一致。漏掉任一环节，浏览器就会静默丢弃 Cookie 或拒绝发送请求。
检查 fetch / axios 的 credentials 配置是否正确
前端发起请求时，必须显式设置凭据模式，不能依赖默认值（默认为 'omit'）：
-
fetch(url, { credentials: 'include' })—— 最常用，要求后端允许且 Cookie 同源或已配置SameSite=None; Secure -
credentials: 'same-origin'—— 仅同域发送 Cookie，跨域时等价于不发，调试时容易误以为“没生效” -
credentials: 'omit'—— 强制不带 Cookie，即使有也会被忽略（这是默认值，常被遗忘）
注意：使用 credentials: 'include' 时，若后端未返回 Access-Control-Allow-Origin: *（而用了具体域名），则必须匹配 Origin 值，不能用通配符。
验证响应头是否满足 CORS 凭据要求
浏览器在收到响应后，会严格校验以下两个响应头：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
Access-Control-Allow-Origin：必须是明确的源（如https://example.com），不能是* -
Access-Control-Allow-Credentials: true：必须存在且值为true（小写，字符串值）
如果这两个头缺失或不合规，控制台会报错：Failed to fetch: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'。可通过浏览器 Network 面板 → 请求详情 → Response Headers 查看。
确认 Cookie 本身是否满足跨域发送条件
即使请求和响应都配置正确，Cookie 若不满足安全属性，浏览器也不会自动带上：
-
Secure：Cookie 必须标记Secure，才能在 HTTPS 环境下参与跨域请求（HTTP 站点无法设置SecureCookie） -
SameSite：跨域场景需设为SameSite=None，且必须搭配Secure（即SameSite=None; Secure） -
Domain：若跨子域（如从app.example.com到api.example.com），需显式指定Domain=example.com，且不能带前导点（现代浏览器已放宽，但仍建议规范写法）
可在浏览器 Application → Cookies 中查看目标 Cookie 的属性，确认三项是否齐全。
快速定位技巧：用 curl 模拟排除前端干扰
当怀疑是前端代码问题时，可用 curl 绕过 JS 环境直接测试服务端行为：
curl -v -H "Origin: https://example.com" \
-H "Cookie: sessionid=abc123" \
https://api.example.com/data
观察响应头中是否有 Access-Control-Allow-Origin: https://example.com 和 Access-Control-Allow-Credentials: true。这样能快速区分问题是出在前端配置、后端响应头，还是 Cookie 本身。
