以前在做网站ref="/tag/177/" style="color:#874873;font-weight:bold;">安全策略时，如果想收集内容安全相关的违规事件，比如某个脚本被拦截了，通常会用到 Content-Security-Policy 里的 report-uri 指令。这个指令能让浏览器把问题上报到指定地址，方便开发者排查。
但最近几年，这个写法慢慢不推荐了。取而代之的是一个更灵活、更统一的机制：report-to。它不只是给 CSP 用的，还能被其他安全策略共用，比如 Expect-CT 或 Network Error Logging。
从 report-uri 到 report-to 的变化
原来的 report-uri 是直接写在策略里的：
Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint现在这种方式已经被标记为废弃。新的做法是配合 Report-To 头部和 report-to 指令一起使用。
首先，服务器要发送一个 Report-To 头，定义上报组和目标地址：
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/reports"}],"include_subdomains":true}然后在 CSP 策略中引用这个组名：
Content-Security-Policy: default-src 'self'; report-to csp-endpoint为什么换成 report-to？
最大的好处是复用。比如你的站点同时启用了 CSP 和 Expect-CT，以前得写两个不同的上报地址，现在可以统一指向同一个 Report-To 组。
另外，report-to 支持更精细的控制，比如上报频率、是否包含子域名、失败重试机制等，这些在旧的 report-uri 上很难实现。
实际使用注意点
目前主流浏览器对 report-to 的支持已经比较完善，但并不是所有环境都完全兼容。如果你还在维护老项目，可能需要保留 report-uri 做降级处理。
不过新项目建议直接上 report-to，毕竟这是未来的方向。而且很多现代框架和 CDN 平台也开始默认支持这种模式。
举个例子，你在调试一个前端页面时发现控制台报错“Refused to load script”，但不知道具体是哪个资源被拦了。只要配置好 report-to，这类信息就会自动发到你的日志服务里，查起来方便多了。