工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 CSP 控制页面能从哪里执行与连接，但不替代输入转义。实时应用尤其要枚举 wss、API、错误上报和 Worker 来源，避免为了修一个报错放开整个通配域。
安全评审要从资产、攻击者能力和信任边界出发，并在每次状态转换重新授权。输入校验、速率限制和审计只能互补，任何一个都不能替代权限判断。
工程边界与取舍
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 脚本使用每响应随机 nonce 和 strict-dynamic，禁用 object-src 与 base-uri；connect-src 仅列实际域，策略先 report-only 收集受控样本。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“实时 Web 应用的 CSP：收紧脚本又不破坏 WebRTC 和 Worker”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 为支持一个第三方统计脚本加入 unsafe-inline 会失去核心保护；上报完整 blocked-uri 又可能泄露查询参数和连接码。
- 刷新或网络切换同时触发两条恢复路径，重复副作用被误当成两次真实用户操作。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
把测试跑成闭环
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 逐页执行主要功能并触发内联脚本、未知连接和 Worker，确认合法路径零违规、攻击样本被阻止且报告已脱敏。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。