CSP 配置错误主要影响的是资源能否正常加载，而非传统意义上的性能指标；配置过严会导致脚本样式被拦截，配置过松则失去安全意义，建议先用 Report-Only 模式测试再正式启用。
先说结论：CSP 配置错误会让浏览器拒绝加载不符合策略的资源，表现为页面功能异常或样式丢失，这属于可用性问题而非单纯的性能损耗。CSP 策略本身的解析开销极小，不会显著影响页面加载速度。
- 先判断：确认问题是 CSP 拦截导致还是其他网络问题
- 优先做：使用 Content-Security-Policy-Report-Only 头进行测试，不阻断资源加载
- 再验证：通过浏览器控制台查看 CSP 违规报告，逐步调整策略
CSP 对性能与可用性的影响
从性能角度看，CSP 头部本身会增加 HTTP 响应的大小，每个安全头部都会占用额外的字节，但现代浏览器解析 CSP 策略的开销微乎其微，通常不会造成可感知的加载延迟。
更关键的问题是：配置错误导致的资源拦截会让页面功能失效，用户感知为"页面加载慢"或"功能不能用"，这实际上是可用性问题。例如，关键 JS 被拦截会导致交互失效，CSS 被拦截会导致布局错乱。
另外，中间件（如 Apache）的 CSP 配置可能覆盖应用层的设置，导致你以为配置正确但实际未生效。这种情况在部署到客户环境时尤其常见。
主流服务器配置示例
不同服务器环境配置 CSP 头部的命令不同，以下是常见环境的配置示例。请根据实际业务域名调整 src 白名单。
Nginx 配置：
在 server 或 location 块中添加：
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline';" always;
Apache 配置：
在 .htaccess 或虚拟主机配置中添加（需启用 mod_headers）：
Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com;"
应用层配置（通用原则）：
如果在代码层设置，确保响应头名称准确。避免使用特定框架的私有配置项，除非你明确知道该框架会将其转换为标准 HTTP 头。
安全测试：Report-Only 模式
正式启用 CSP 前，务必使用 Report-Only 模式测试，这样浏览器会报告违规行为但不会阻止资源加载，能让你在不停服的情况下测试策略。
配置方法：
将响应头名称从 Content-Security-Policy 改为 Content-Security-Policy-Report-Only。
Nginx 示例：
add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report;" always;
注意：report-uri 指令已逐渐被 report-to 取代，但前者兼容性更好。若需收集报告，需后端提供接收接口。
验证与排查步骤
步骤一：确认问题来源
在浏览器控制台查看错误信息，典型的 CSP 拦截错误会显示：
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'"
如果看到这类信息，说明是 CSP 策略问题；如果没有 CSP 相关报错，需要排查其他原因。
步骤二：检查资源加载状态
打开浏览器开发者工具（F12），查看 Network 面板中资源的加载状态，确认是否被浏览器阻止（通常显示为 blocked 或 failed）。
步骤三：整理资源来源清单
根据控制台报错，列出所有被拦截的资源域名，包括脚本来源（script-src）、样式来源（style-src）、图片来源（img-src）等。
步骤四：检查中间件配置
如果应用层配置正确但问题依旧，检查是否有反向代理（如 Apache、Nginx）覆盖了 CSP 头。关闭中间件的 CSP 配置或删除其设置，让应用层的配置生效。
怎么验证是否生效
1. 刷新页面后，浏览器控制台不应再出现 CSP 拦截错误
2. Network 面板中所有资源的状态码应为 200 或 304，而非被阻止
3. 页面功能（如按钮点击、表单提交）应正常工作
4. 样式应正常显示，无布局错乱
5. 如果使用 Report-Only 模式，可以在控制台看到违规报告但不影响加载，确认无误后再切换到正式模式
常见坑
1. 中间件覆盖：Apache、Nginx 等反向代理的 CSP 配置会覆盖应用层设置，部署时需检查整条链路
2. 内联脚本处理：避免直接允许unsafe-inline，优先使用 nonce 或 hash 方式，否则会降低安全性
3. 多策略冲突：同时存在多个 CSP 头时，浏览器会取最严格的策略，可能导致意外拦截
4. 本地开发环境：开发时可能需要允许 localhost 相关源，但生产环境应收紧策略
5. 第三方资源：CDN、字体库、分析工具等第三方资源需提前列入白名单，否则上线后会突然失效
6. 缓存问题：修改 CSP 头后，浏览器可能缓存旧策略，需要清除缓存或使用强制刷新
参考文档
- MDN Web Docs: Content Security Policy (CSP)
- Google Developers: Content Security Policy
- W3C: Content Security Policy Level 3