为何Fetch请求返回Response type为"cors"？配置*仍有CORS问题？

1. 响应type为cors是否意味着被CORS拦截？ #

不是。type: 'cors'是浏览器对跨域请求的正常标记，它表示：

• 当前请求属于跨域请求
• 服务器返回了符合CORS规范的响应头
• 浏览器允许你的代码读取该响应的内容

如果请求真的被CORS拦截，浏览器会直接抛出Access-Control-Allow-Origin相关的错误，你根本无法获取到这个响应对象。

2. 配置了Access-Control-Allow-Origin: *仍有CORS问题的可能原因 #

以下是几种常见的触发场景：

• 请求包含凭据（Credentials）：如果你的fetch请求设置了credentials: 'include'（比如携带Cookie、HTTP认证信息），Access-Control-Allow-Origin不能使用*，必须指定具体的请求源域名。即使你没显式设置，某些场景下浏览器也可能自动带上凭据，导致规则冲突。
• Vary: Origin头的潜在问题：响应头包含Vary: Origin，说明服务器会根据请求的Origin头返回不同的CORS配置。curl请求没有携带Origin头，服务器返回*，但当浏览器发送带真实Origin的请求时，服务器可能没有正确返回匹配的Access-Control-Allow-Origin值（比如配置错误，仅允许特定Origin而非*）。
• CDN/代理缓存不一致：你使用了CloudFront CDN，可能存在缓存的响应没有正确包含CORS头。比如CDN缓存了不带Access-Control-Allow-Origin的旧响应，后续请求直接命中缓存，导致浏览器报错。可以尝试添加缓存破坏参数（如https://example.com/js/chunk-99EP6AU.js?cache-bust=1）测试。
• 额外的CORS头缺失：如果你的请求使用了GET/POST之外的HTTP方法，或者携带了自定义请求头，服务器还需要配置Access-Control-Allow-Methods和Access-Control-Allow-Headers来允许这些操作，仅靠Access-Control-Allow-Origin: *不足以覆盖所有场景。
• 浏览器缓存的旧响应：之前的请求可能返回过不符合CORS要求的响应，浏览器缓存了该结果。清空浏览器缓存后重新测试，看是否解决问题。

内容的提问来源于stack exchange，提问作者Jack Sud