是什么
CORS 报错调试 (跨域资源共享) 是什么
跨域资源共享 (CORS) 检查工具可以帮助您解决浏览器调试中最关键的问题：浏览器是否会允许此请求通过，还是会先在策略层拦截它？与其逐个查阅 CORS 响应头并靠猜，不如在一个地方对比请求方法、自定义请求头、凭据模式和返回的响应头。
这在 API 在 Postman 或 curl 中正常工作但在浏览器中失败的情况下尤其有用。在这种情况下，后端在传输层可能没问题，但由于 CORS 约定不完整或内部不一致，浏览器仍然会拦截响应。
如何使用
如何使用CORS 报错调试 (跨域资源共享)
输入前端源 (Origin)、请求方法以及浏览器将发送的任何自定义请求头。然后填写您的 API 或网关当前返回的响应头，特别是 `Access-Control-Allow-Origin`、`Access-Control-Allow-Methods` 和 `Access-Control-Allow-Headers`。
检查器将告诉您浏览器是否将该请求视为简单请求或预检请求、是否允许该来源，以及预检响应是否确实授予了您所要求的请求方法和请求头。
使用示例
使用示例
场景：
前端源: https://app.aistacker.dev
方法: GET
请求头: authorization, x-client-version
允许源: *
允许方法: GET, POST, OPTIONS
允许头: authorization, x-client-version
携带凭据: true
结果：
浏览器会拦截该请求，因为当 `Access-Control-Allow-Credentials` 为 `true` 时，`Access-Control-Allow-Origin` 不能使用通配符 `*`。请返回具体的源地址。常见使用场景
常见使用场景
1. 解释为什么 API 调用在 curl 中成功但在浏览器中失败。
2. 检查某个自定义请求头是否是预检请求 (Preflight) 失败的真实原因。
3. 验证对于您使用的请求模式，`Access-Control-Allow-Origin: *` 是否安全。
4. 当网关重写或删除 CORS 响应头时，对比本地成功与生产环境失败的情况。
常见问题
常见问题
为什么请求在 Postman 中可以工作，但在浏览器中却失败了？v
Postman 和 curl 不受浏览器 CORS 强制执行模型的约束。服务器在 HTTP 层面可能响应成功，但如果返回的 CORS 响应头不满足浏览器对该请求的策略，浏览器仍会拦截响应。
是否每个跨域请求都会触发预检？v
不是。使用安全方法和简单请求头的简单请求可以跳过预检。一旦您引入自定义请求头、JSON 内容类型或非简单方法（如 PUT 或 PATCH），浏览器就更有可能先发送一个 OPTIONS 预检请求。
为什么当启用凭据时，通配符 Allow-Origin 会失效？v
当 `Access-Control-Allow-Origin` 为 `*` 时，浏览器会拒绝携带凭据的 CORS 响应。一旦涉及凭据，响应通常必须返回具体的允许源，而不是使用通配符模式。