浏览器插件可能静默拦截跨域请求，表现为请求被标记为“blocked”或“canceled”，而非标准CORS错误；需通过无痕模式验证、检查Network面板状态及Initiator来源，重点排查广告拦截器、安全增强类和CORS调试类插件。
浏览器插件确实可能干扰跨域请求，但这类问题不常被想到——它不会报标准的 CORS 错误，而是让请求根本发不出去、被静默拦截，或返回异常状态（如 net::ERR_BLOCKED_BY_CLIENT）。排查时需先排除插件干扰，再回归标准 CORS 分析流程。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
看 Network 面板里请求是否被标记为 “blocked” 或 “canceled”
在火狐或 Chrome 的 Network 标签页中，找到失败的请求行。如果状态列显示：
- blocked（尤其带灰色“广告拦截器”图标）
- canceled 且 Initiator 显示为空或为扩展名（如 adguard.js、uBlock Origin）
- 请求未发出（没有时间线、没有响应头、甚至没有 status code）
这大概率是插件主动阻止了该请求，而非 CORS 拦截。
用无痕/隐私模式快速验证插件影响
无痕窗口默认禁用所有扩展（除个别设为“允许在无痕中运行”的）。操作步骤：
- 打开无痕窗口（Ctrl+Shift+N / Cmd+Shift+N）
- 访问相同页面，复现请求
- 观察控制台和 Network 面板：
• 若错误消失、请求正常发出并收到响应 → 插件是元凶
• 若仍报 Blocked by CORS policy → 回归标准 CORS 排查
逐个禁用可疑插件，重点关照这几类
以下插件类型最常误伤跨域资源加载：
- 广告/跟踪拦截器（uBlock Origin、AdGuard、Privacy Badger）：可能把 API 域名识别为第三方 tracker
- 安全增强类（HTTPS Everywhere、NoScript）：可能强制升级协议或阻止非 HTTPS 资源
- CORS 调试插件（CORS Everywhere、Allow CORS）：若配置不当，反而覆盖或冲突真实响应头
- 自定义脚本管理器（Tampermonkey）：用户脚本可能篡改 fetch / XMLHttpRequest 行为
检查请求发起源头是否被插件重写或拦截
点击 Network 中的请求 → 切换到 Headers 标签 → 查看 Request URL 和 Referrer：
- 如果 Request URL 被重定向到一个奇怪地址（如 https://redirect.example.com/?url=...），可能是插件注入了代理逻辑
- 如果 Referrer 为空，而你代码中明确设置了 referrerpolicy="no-referrer"，也可能是插件清除了它
- 在 Initiator 标签页中，若显示为某个 .js 文件路径，且该路径属于扩展目录（如 chrome-extension://abc123/...），说明插件劫持了请求链
