CORS配置错误须修正服务端响应头：①Access-Control-Allow-Origin需按credentials情况设具体域名或动态Origin；②OPTIONS预检须返回200及完整CORS头；③启用credentials时必须同时设Allow-Credentials:true与非*的Origin；④自定义响应头需通过Expose-Headers显式暴露。
处理 CORS 响应头配置错误，关键在于识别错误类型后精准修正服务端响应头，而不是在前端“想办法绕过”。浏览器只认服务端返回的头字段，错一个就报错，常见错误基本都对应明确的修复动作。
检查并修正 Access-Control-Allow-Origin 配置
这是最常出错的响应头。错误表现通常是控制台报“No 'Access-Control-Allow-Origin' header is present”或“origin does not match”。需注意：
- 若前端请求带 credentials（如 credentials: 'include' 或 withCredentials = true），后端 不能设为 *，必须写具体源，例如 https://myapp.com 或动态回传请求头中的 Origin 值
- 开发环境用 * 可以快速验证，但上线前必须替换为白名单域名或做 Origin 校验逻辑
- 确保该头出现在所有相关接口响应中——包括 4xx/5xx 错误响应，否则错误路径也会触发 CORS 拒绝
确认预检请求（OPTIONS）是否被正确响应
当请求含 Authorization、Content-Type: application/json、PUT/DELETE 方法 时，浏览器会先发 OPTIONS 请求。失败常表现为“preflight request failed”。必须做到：
- 对所有 OPTIONS 路径（尤其是 API 路由）返回 200 OK 状态码，不走业务逻辑
- 响应中必须包含完整 CORS 头：Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers，且值要与实际请求匹配
- 例如前端发了 Authorization 头，后端 Access-Control-Allow-Headers 就必须包含它，大小写不敏感但拼写必须一致
核对 credentials 相关头的组合一致性
前后端 credentials 配置不一致是静默失败的高发原因。典型错误提示是：“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'”。解决要点：
立即学习“Java免费学习笔记（深入）”；
- 前端设 credentials: 'include' → 后端必须同时设 Access-Control-Allow-Credentials: true + Access-Control-Allow-Origin: https://xxx.com（不能是 *）
- 后端若漏掉 Access-Control-Allow-Credentials: true，即使 Origin 正确，浏览器也拒绝暴露响应
- 注意：一旦启用 credentials，所有跨域请求都会携带 Cookie，后端需确保 session 或鉴权逻辑能正常处理
验证自定义响应头是否被显式暴露
如果前端 JS 需要读取响应里的自定义头（比如 X-Request-ID、X-Total-Count），但 fetch 拿不到，大概率是没配 Access-Control-Expose-Headers：
- 默认只暴露简单响应头（Cache-Control、Content-Language、Content-Type 等）
- 需在后端响应中添加类似 Access-Control-Expose-Headers: X-Request-ID, X-Total-Count 的头
- 多个头用英文逗号+空格分隔，注意不要多加空格或拼写错误
