浏览器拦截 fetch 跨域请求本质是同源策略限制，请求通常已抵达服务端，但浏览器丢弃响应；需从请求是否发出、响应是否返回、响应头是否合规三方面排查。
浏览器拦截 Fetch 请求的跨域问题，本质是违反了同源策略，而 不是请求没发出去——请求通常已到达服务端，但浏览器在收到响应后主动丢弃，并在控制台报错。排查需从“请求是否发出”“响应是否返回”“响应头是否合规”三方面入手。
看控制台 Network 面板确认请求真实状态
打开开发者工具 → Network 标签页，发起请求后找对应条目：
- 如果请求条目显示 status canceled 或 blocked: cross-origin（Chrome 120+），说明被预检（OPTIONS）或主请求被浏览器直接拦截，服务端根本没收到请求；
- 如果能看到 status 200/4xx/5xx 且有响应内容（Preview/Response 标签可见），说明请求已抵达服务端，问题出在响应头缺失或错误；
- 点击该请求 → Headers 标签 → 检查 Response Headers 中是否有
Access-Control-Allow-Origin，值是否匹配当前页面源（如https://a.com），且不能为通配符*（当请求带 credentials 时）。
检查是否触发了 CORS 预检（OPTIONS 请求）
当 Fetch 满足以下任一条件时，浏览器会先发一个 OPTIONS 预检请求：
- 使用了除 GET/HEAD/POST 外的方法（如 PUT、DELETE）；
- 设置了自定义请求头（如
Authorization、X-Request-ID）； - Content-Type 值不是
application/x-www-form-urlencoded、multipart/form-data或text/plain（例如用了application/json）。
若 Network 中看到 OPTIONS 请求失败（如 404、403、无响应头），主请求就不会发出。此时需确保服务端正确处理 OPTIONS，并返回合法的 CORS 响应头（包括 Access-Control-Allow-Methods、Access-Control-Allow-Headers 等）。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
验证 credentials 和响应头的兼容性
如果 Fetch 配置了 credentials: 'include'（或 'same-origin'），则服务端的 Access-Control-Allow-Origin 不能写成 *，必须明确指定源（如 https://a.com），同时建议返回 Access-Control-Allow-Credentials: true。否则浏览器会静默拒绝响应。
用 curl 或 Postman 绕过浏览器验证服务端行为
在终端执行：
curl -H "Origin: https://a.com" \
-H "Access-Control-Request-Method: POST" \
-X OPTIONS -I http://your-api.com/endpoint
观察响应头是否包含正确的 CORS 字段。这能排除前端代码干扰，确认问题是否真在服务端配置。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
