nonce 是 csp 中允许内联脚本的安全机制，需服务端动态生成并严格匹配响应头与 script 标签中的值；不支持 meta 标签设置，且对 eval 和内联事件无效。
nonce 属性不能“配合” CSP script 白名单，它本身就是白名单机制的一种实现方式——而且是比 'unsafe-inline' 更安全、比哈希值更灵活的替代方案。
为什么直接写 script 标签会触发 CSP 拒绝？
当你在 HTML 里写 <script>alert(1)</script> 或内联事件如 <button onclick="doSomething()"></button>，浏览器会把它视为“内联脚本”。默认情况下，CSP 策略若未显式允许（比如没加 'unsafe-inline'），就会直接拦截执行，控制台报错类似：
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'".
这个错误不是“没配好”，而是 CSP 在严格执行——它不信任任何未声明来源的脚本代码。
nonce 是怎么让内联脚本“变合法”的？
服务端在生成 HTML 响应时，为每个请求动态生成一个一次性随机字符串（比如 27f434278e6b79578d5c9f0a321c4567），通过 HTTP 响应头或 <meta> 注入到 CSP 策略中，并同步写进 <script nonce="..."></script> 标签。浏览器只认“nonce 值完全匹配”的内联脚本。
- CSP 响应头必须包含该 nonce：
Content-Security-Policy: script-src 'self' 'nonce-27f434278e6b79578d5c9f0a321c4567' - 对应脚本标签必须带相同值：
<script nonce="27f434278e6b79578d5c9f0a321c4567">console.log('ok');</script> - nonce 值不能硬编码，也不能复用——每次 HTTP 响应都要新生成，否则失去防 XSS 意义
- 注意大小写敏感，且中间不能有空格或换行
常见踩坑点：nonce 不生效的几个典型原因
即使写了 nonce，脚本仍被拦截，大概率是以下某一项出问题：
- CSP 响应头里的
'nonce-xxx'和<script nonce="xxx"></script>的值**字符不完全一致**（比如多了空格、用了全角引号、大小写混用） - 服务端把 nonce 插入了
<meta http-equiv="Content-Security-Policy">，但该方式**不支持 nonce**（仅响应头有效） - 用了模板引擎（如 Jinja2、EJS），但变量插值时没做 HTML 安全转义，导致 nonce 字符串被截断或注入失败
- 前端构建工具（如 Webpack/Vite）自动注入的内联脚本（比如 HMR 逻辑）没带上 nonce，需要额外配置
__webpack_nonce__或使用script-src-elem分离控制 - HTTP 响应头设置了多个 CSP 策略（例如同时有
Content-Security-Policy和Content-Security-Policy-Report-Only），但只有其中一个含 nonce，而浏览器按最严策略执行
和哈希值（'sha256-...'）比，nonce 适合什么场景？
nonce 不是万能替代，它的适用性取决于你能否控制服务端输出流程：
- 适合：SSR 页面、模板渲染、需动态插入初始化脚本（如 JSON 数据预置、用户权限上下文）
- 不适合：纯静态 HTML 文件（无法每次生成新 nonce）、CDN 缓存的页面（缓存会固定 nonce，失去安全性）
- 哈希更适合：构建时确定内容的内联脚本（如 Vue/React 的根挂载代码），但一旦脚本内容变更就必须重算哈希
- 注意：
nonce对eval()、setTimeout("string")、内联事件属性（onclick）同样无效——这些仍需显式允许'unsafe-eval'（不推荐）或改用事件监听器
真正难的不是写对 nonce 字符串，而是确保它从服务端生成、注入、传输、校验这一整条链路不被绕过或缓存固化。一旦漏掉任意一环，它就退化成摆设。
