必须同时满足前端 credentials: 'include'、服务端 Access-Control-Allow-Credentials: true 且 Access-Control-Allow-Origin 为具体源（不能为 *），三者缺一不可；因浏览器强制限制，携带凭证时 Origin 不得通配，否则静默丢弃响应。
前端 JavaScript 发起跨域请求时，若需携带 Cookie、HTTP 认证信息（如 Bearer Token）或客户端证书等凭证，必须同时满足服务端和前端两方面的严格配合。关键在于 Access-Control-Allow-Credentials 响应头的启用，以及它与 Access-Control-Allow-Origin 的协同约束——二者不能随意组合，否则浏览器会直接拒绝响应。
为什么 Access-Control-Allow-Credentials 不能配 *
当服务端设置 Access-Control-Allow-Credentials: true 时，浏览器要求 Access-Control-Allow-Origin 必须是**具体协议+域名+端口**（例如 https://app.example.com），而不能是通配符 *。这是硬性安全限制，不是配置疏漏。一旦违反，控制台会报错：
原因在于：凭证（如 Cookie）具有用户身份敏感性，若允许任意源（*）都能读取带凭证的响应，将极大增加 CSRF 和信息泄露风险。
前后端必须同步开启凭证支持
仅服务端设 credentials: true 不够，前端发起请求时也必须显式声明携带凭证：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 使用
fetch时，添加credentials: 'include'选项 - 使用
XMLHttpRequest时，调用xhr.withCredentials = true - 若用 axios，默认不发 Cookie；需配置
{ withCredentials: true }
注意：即使后端已正确返回 Access-Control-Allow-Credentials: true，前端未设 credentials，请求仍不会携带 Cookie，且后续响应也不会被 JS 读取（除非服务端还设置了 Access-Control-Expose-Headers 暴露自定义头）。
常见配置陷阱与修复示例
以下错误在开发中高频出现：
-
本地开发环境误用 localhost 不同端口：前端
http://localhost:5173请求后端http://localhost:8080，虽同为 localhost，但端口不同即跨域；此时Origin是http://localhost:5173，服务端必须精确匹配，不能写成http://localhost或漏掉端口 -
Nginx 网关层只加头，未透传 OPTIONS：若预检请求（OPTIONS）被网关拦截或未返回完整 CORS 头（尤其缺
Access-Control-Allow-Credentials），主请求永远无法发出；需确保 OPTIONS 路径也返回全部必要头 -
Spring Boot @CrossOrigin 注解未设 allowCredentials：仅写
@CrossOrigin(origins = "https://app.com")默认不开启凭证；必须显式加allowCredentials = "true"
Cookie 跨域生效的附加条件
除了 CORS 头，Cookie 本身还需满足以下任一条件才能被跨域请求携带：
- 服务端 Set-Cookie 响应头中包含
SameSite=None; Secure（HTTPS 环境下必须） - 若为开发环境 HTTP 协议，部分浏览器（如 Chrome）要求
SameSite=Lax或Strict才允许发送，但此时无法跨域；建议开发阶段用 HTTPS + localhost 或配置浏览器启动参数绕过限制 - Cookie 的
Domain属性需覆盖请求目标域名（例如后端接口在api.example.com，Cookie Domain 应设为.example.com）
