跨域请求失败是浏览器拦截响应而非请求未发出，关键排查：看控制台错误定位拦截环节（如缺少Access-Control-Allow-Origin头、OPTIONS预检失败或credentials与*冲突），查Network中Origin与响应头是否匹配，确认服务端日志是否收到请求，并排除代理、插件等干扰。
跨域请求失败，不是请求发不出去，而是浏览器在收到响应后拒绝把内容交给 JavaScript。排查关键在于分清“谁拦的”“为什么拦”“拦在哪一步”。
看控制台错误类型，快速定位拦截环节
浏览器控制台报错信息是第一线索：
- 出现 "No 'Access-Control-Allow-Origin' header"：说明服务端响应里没带这个头，或值不匹配，问题在服务端 CORS 配置
- 报错含 "preflight is invalid" 或 OPTIONS 请求返回 404/405：预检失败，服务端没正确处理 OPTIONS 方法，或没返回 Allow-Methods/Allow-Headers
- 提示 "Credentials not supported" 或 “The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*'”：前端带了 credentials（如 cookie），但后端 Allow-Origin 设成了 *，二者配置冲突
- 没有 CORS 报错，但 Network 里请求状态是 pending 或直接消失：可能被网关、代理、防火墙拦截，或 SSE/WebSocket 被中间层断连，不属于浏览器同源策略范畴
查 Network 请求细节，验证前后端是否对齐
在 Chrome 或 Edge 的 Network 面板中，点开失败的请求，重点核对：
- Request Headers 中是否有 Origin 字段，值是否是你前端的实际地址（如 https://admin.example.com）
- Response Headers 中是否存在 Access-Control-Allow-Origin，且值与 Origin 完全一致（不能是 * + credentials）
- 如果请求带 Authorization 或 Content-Type: application/json，检查是否有 OPTIONS 预检请求；它的响应头里是否包含 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers
- 响应状态码不是 2xx（比如 401/403）：说明请求已抵达服务端，但被业务逻辑拦截，CORS 不是主因，需查鉴权或路由逻辑
确认服务端是否真收到请求
浏览器报错只是表象，服务端日志才是真相：
立即学习“Java免费学习笔记（深入）”；
- 如果服务端日志里完全没这条请求记录 → 请求可能被 Nginx、CDN、WAF 或网关提前拦截（例如未放行 OPTIONS，或路径规则误配）
- 如果日志显示请求已进入业务代码，且返回了 200 → 浏览器 CORS 拦截成立，问题一定出在响应头缺失或不合法
- 特别注意：Node.js 等服务若用 express，cors 中间件必须放在所有路由之前，否则中间件不生效
排除开发环境干扰项
本地调试时容易误判，先做这几步再深入：
- 用 curl 或 Postman 直接访问接口，看原始响应头是否含 CORS 字段（绕过浏览器限制）
- 临时禁用浏览器插件（尤其是广告拦截、隐私保护类），它们可能改写请求头或拦截特定域名
- 检查前端 fetch/fetch 或 axios 是否显式设置了 mode: 'no-cors' —— 这会让响应变成 opaque，JS 根本读不到 body，不是解决办法，是掩盖问题
- Vite/webpack devServer 代理只在开发环境起作用，上线后失效，别把它当成生产解法
