必须后端配置 access-control-allow-credentials: true 且 access-control-allow-origin 为具体源（不能为*），因前端 credentials: 'include' 触发凭证校验，浏览器强制要求这两头匹配，否则拒绝响应。
后端配了 CORS，前端带 credentials: 'include' 却报错“Access-Control-Allow-Credentials header is ''”，说明服务端漏写了凭证相关响应头——这不是前端能绕过的限制，必须前后端对齐配置。
确认是否触发了凭证校验
浏览器只在请求明确携带凭据时，才强制要求服务端返回 Access-Control-Allow-Credentials: true。常见触发场景包括：
- 前端 fetch 或 axios 设置了
credentials: 'include'（或'same-origin'） - 请求自动携带 Cookie（如未显式设
credentials: 'omit'，且当前页面与目标域满足 Cookie 同源策略） - 使用了
withCredentials = true的 XMLHttpRequest
检查响应头是否缺失或冲突
打开浏览器 Network 面板，找到失败的请求，点击它，查看 Response Headers 标签页：
- 必须存在
Access-Control-Allow-Credentials: true（注意值是字符串 true，不是布尔值或空字符串） -
Access-Control-Allow-Origin不能为*，必须是具体源，例如http://localhost:3000或https://myapp.com - 若这两个头同时缺失、值为空、或 Origin 是通配符而 Credentials 为 true，浏览器会直接拒绝响应
排查后端常见配置陷阱
不同框架容易漏掉凭证头，尤其升级后行为变更：
-
@koa/cors v5+：默认
origin: '*'，但启用credentials: true时必须改用函数形式返回具体 origin，否则响应头中Access-Control-Allow-Origin仍为* -
Express cors 中间件：若只写
credentials: true但没配origin函数，默认 origin 仍是*，导致冲突 -
Gin / Spring Boot 等：需显式开启 allowCredentials 并绑定非通配 origin；部分中间件默认不返回该头，需手动加
addHeader("Access-Control-Allow-Credentials", "true")
验证预检请求是否也合规
如果请求含自定义 header（如 Authorization）或使用非简单方法（PUT/DELETE），浏览器会先发 OPTIONS 预检。此时：
- OPTIONS 响应中也必须包含
Access-Control-Allow-Credentials: true - 且
Access-Control-Allow-Origin同样不能为* - 确保后端对 OPTIONS 请求也走同一套 CORS 配置逻辑，而非跳过中间件
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
