为什么 Access-Control-Allow-Origin 为 * 时会在 credentials 模式下失败
从浏览器执行规则出发，解释为什么当前端发送 cookies 或带凭证请求时，`Access-Control-Allow-Origin: *` 会直接触发 CORS 阻止。
在 CORS 排障里，最让人困惑的一类问题就是：配置表面上看起来很“开放”，浏览器里却依然失败。接口明明返回了 Access-Control-Allow-Origin: *，在 Postman 里也能成功，于是团队很容易误以为后端已经放通。可一旦前端开始携带 cookies 或其他凭证状态，浏览器就会直接把响应拦下。
关键在于，不要把 wildcard CORS 理解成“任何场景都够开放”。对于匿名的公开读取，* 可能是可以工作的；但对于带 credentials 的浏览器请求，浏览器需要的是更明确的允许关系。此时 * 不再被视为足够安全的声明。
先把它看成浏览器规则问题，而不是 API 本身坏了
团队之所以容易在这里浪费时间，是因为同一个请求在浏览器外经常可以成功。Postman、curl 或服务端脚本不会执行浏览器那套 CORS 安全策略。所以接口在 HTTP 层面完全可达，并不意味着浏览器愿意把这个响应交给前端 JavaScript。
因此第一步不该问“API 有没有返回数据”，而应该问“浏览器是否认为这个 origin 和当前凭证模式下的响应是安全的”。只要先把问题固定在这个边界上，你就会意识到 wildcard 不是“已经足够宽松”，而是“对于这个场景仍然不完整”。
理解为什么一旦有 credentials，wildcard Allow-Origin 就会失效
浏览器对带 credentials 的跨域请求会更严格，因为这类请求可能携带 cookies、登录状态或其他敏感上下文。如果响应写的是 Access-Control-Allow-Origin: *，浏览器无法把这种“对所有源开放”的承诺和带凭证访问安全地结合起来，所以会直接阻止。
换句话说，问题不在于服务端拒绝了请求，而在于浏览器不信任这种 wildcard 响应。实际修复时，通常需要返回明确的前端 origin，或者至少只对白名单中的 origin 做精确允许，并让 credentials 规则与之保持一致。
本节相关工具
把排查拆成两个步骤，而不是把它当成一个模糊的失败
更可靠的排查方式，是把浏览器的判断拆成两步。第一步，确认 method 或 custom headers 是否触发了 preflight。第二步，再确认最终响应头在 credentials 条件下是否仍然成立。很多团队只盯着应用路由，忽略了浏览器可能在更前面的策略层就已经拒绝了。
建议按这个顺序检查：
- 先确认请求是 simple 还是 preflighted。
- 对照 preflight 返回头，确认 method 和 custom headers 是否真的被允许。
- 检查最终响应中的
Access-Control-Allow-Origin是否对凭证模式足够明确。 - 确认生产环境里的代理、CDN 或认证层没有在应用返回之后重写这些头。
这会比盲目改 header 再反复发布更快，也更接近真实问题边界。
CORS Header Checker
Check whether a browser request will pass CORS based on the request method, custom headers, credentials mode, and the response headers your API returns.
HTTP Status Code Explorer
Search common HTTP status codes, compare confusing client and server failures, and keep a sharper API debugging checklist in the browser.
JWT Decoder
Decode and inspect JWT tokens instantly to view headers, payloads, and expiration status locally in your browser.