csp对fetch请求的硬性限制由connect-src指令决定，浏览器在发起前静默拦截，network中显示(canceled)、无状态码、无响应头、无promise reject。
识别 CSP 对 fetch 请求域名的硬性限制，关键在于确认 connect-src 指令是否覆盖目标 API 域名，且浏览器在发起请求前就已拦截——这种拦截不产生 HTTP 状态码，也不触发 Promise reject，而是直接标记为 (canceled) 或静默失败。
一、看 Network 面板中的请求状态异常
当 fetch 调用无声失败时，打开 Chrome DevTools 的 Network 面板，筛选 XHR/Fetch 类型请求，重点关注以下特征：
- 请求条目显示
Status为空或标为(canceled)，而非 4xx/5xx - Initiator 列指向
fetch()或 Service Worker 的fetch事件监听器，但 Timing 标签页中无 DNS / Connect / Request 启动记录 - Response 标签页为空，Headers 中看不到任何响应头（包括没有 CORS 相关 header）
- 控制台无 JavaScript 报错，但 Report-To 端点（如有配置）持续收到
content-security-policy-report类型 violation
二、查 CSP 响应头与 connect-src 是否匹配
CSP 对 fetch 的限制由 connect-src 指令单独控制，与 script-src 或 default-src 无关。需逐项核对：
- 检查服务器返回的
Content-Security-Policy响应头，提取connect-src值（如未显式声明，则回退到default-src） - 确认目标 fetch URL 的 origin（协议+域名+端口）是否被明确允许：例如请求
https://api.example.com/v1/data，则connect-src必须包含https://api.example.com或'self'（若同源） - 注意通配符限制：
https://*.example.com允许子域名，但*不允许带端口或协议降级；data:、blob:等非 HTTP 协议需单独列出
三、验证是否因自定义 Header 触发预检阻断
Chrome 115+ 对含敏感 header（如 Authorization、X-Requested-With）的 fetch 请求，在 connect-src 检查前还会做“语义归类”预检。若 header 被识别为 unsafe-request-header，而 CSP 未显式允许，请求会在构造阶段被内核静默拒绝：
- 临时移除 fetch 的
headers选项，仅保留 URL 和 method，观察是否恢复成功 - 若移除后正常，再逐一添加 header 测试，定位触发拦截的具体字段
- 常见高危 header：Authorization、Cookie、Host、Origin、Referer（部分版本）、Sec-* 系列（如 Sec-Fetch-Mode）
- 解决方案：确保
connect-src明确包含目标 origin；避免在非必要场景携带敏感 header；或改用后端代理中转
四、用 report-only 模式快速定位策略冲突
将 CSP 改为只报告不执行模式，可捕获所有潜在拦截而不影响功能：
- 将响应头从
Content-Security-Policy改为Content-Security-Policy-Report-Only - 配置
report-to指令指向一个接收 violation 日志的 endpoint（如report-to: csp-report-endpoint） - 复现 fetch 行为，查看上报日志中的
blocked-uri和violated-directive字段，精准定位是connect-src还是其他指令（如script-src误配影响 SW）导致 - 注意：report-only 模式下，浏览器仍会执行请求，因此可用于安全灰度验证
