内容安全策略先只上报不拦截，看什么再决定真的拦下来

内容安全策略先用只上报模式跑一段，看哪些信息之后再决定拦截——这是上线这条规则时最稳的顺序。文档口径说得很直接：只上报的做法用于测试阶段，报告违规但不阻止代码执行。它的价值不在于「先温和一点」，而在于让你拿到一份真实访问条件下产生的违例清单，再决定哪几条要拦、哪几条要先改页面。

只上报模式解决什么问题

直接开拦截最常见的事故是页面功能性失效：样式被挡、第三方组件加载不出来、内联脚本停用后交互报错。这些在测试环境里往往看不全，因为真实访问里混着浏览器扩展、代理注入和不同版本的客户端。

只上报模式把判定与执行分开：规则照常评估，违例照常记录，页面照常渲染。这样你可以在不影响访客的前提下，收集一到两周的数据，把「必须放行的来源」和「确实要挡的注入」区分开。对以内容为主的站点，这一步尤其重要，因为富文本里的内联样式与嵌入内容最容易误伤。

报告目标为什么要写两处

上报地址有两种写法：旧的地址型写法和新的端点型写法。文档提示新式写法被设计用来取代旧式，在支持新式的浏览器里，旧式指令会被忽略。这意味着只写一处会出现两种坏情况——只写旧式，新浏览器不上报；只写新式，老客户端不上报。

兼容期的做法是两处都给：同一份策略里同时带旧地址与新端点名，并另外声明端点的实际接收地址。接收端要做去重，因为同一个违例可能从不同写法上报两次。报告地址本身要用站内路径或同域端点，跨域上报还要额外处理，这也是不少站点收不到报告的原因。

灰度期看哪几类信息

第一类是频次最高的违例来源，通常能归成三种：嵌入内容、统计脚本、浏览器扩展注入。前两种要在策略里给出明确来源，第三种要从记录里排除——它们的域名五花八门，但都不在你控制的代码里，误把它们当成待拦截目标会把规则越写越宽。

第二类是内联脚本与内联样式。内容型站点的富文本经常带内联属性，直接禁止会让排版走样。这一类要么改模板把样式抽出去，要么接受一个更宽的例外，选择要基于违例记录里的真实比例。

第三类是被重定向到别处的资源。策略对来源的匹配是按最终地址判断的，带跳转的资源经常被判违规，这类要在源头改成直连地址，而不是给跳转开例外。

打开拦截时的回退

切换时按段来：先对少数路径开拦截，确认无违例后扩大到整站。保留一条回退手段，出现功能性故障时能立刻退回只上报，而不是临时在策略里加例外——临时例外往往一去就不回来。

改模板时这一层要连着看。站内的可视化模板编辑能力会同时影响样式引用与脚本引用，动公共头尾时要把策略允许的写法一起核对，否则模板改完页面空白，问题却报在策略里。如果同批还涉及跨站脚本防护（XSS）相关的清洗规则，要把两处改动分开上线，方便归因。

常见问题

只上报要跑多久？ 覆盖一个完整的内容与活动周期，通常按一到两周计，节日类站点要包含高峰期；时间过短会漏掉少见的嵌入形态。

收不到报告怎么排查？ 依次确认报告地址是否可访问、是否被同源限制挡住、两处写法是否都给了，以及接收端有没有把重复记录丢弃。

能不开拦截只留上报吗？ 可以，长期只上报等于没有防护，只把它当过渡；确认违例可控后应切拦截。

违例量突然变大是什么原因？ 多来自第三方脚本换域名或模板改动，先比对违例来源与最近一次模板、依赖变更的时间，而不是急着加例外。