第三方弹窗SDK动态插入的script标签必须携带服务端生成的nonce值，且CSP需配置'strict-dynamic'，否则浏览器静默丢弃执行；SDK自身不感知nonce，补设无效；有效方式仅两种：①内联初始化脚本由服务端渲染并显式带nonce；②runtime脚本通过模板注入并控制script标签输出。
第三方弹窗SDK挂载时nonce怎么传才不被浏览器拦
直接结论：第三方弹窗SDK动态插入的 <script> 标签，若没带服务端生成的 nonce 值，且 CSP 头里没配 'strict-dynamic'，浏览器会直接拒绝执行——不是报错，是静默丢弃，连 console 都不会出提示。
- SDK 本身不感知 nonce：绝大多数弹窗 SDK（比如客服浮窗、AI 智能体弹窗）默认用
document.createElement('script')动态加载资源或执行初始化逻辑，它不会主动读取页面已有的nonce属性 - 你不能靠 JS 在 DOM 加载后“补” nonce：浏览器在 HTML 解析阶段就完成 nonce 校验，
script.nonce = 'xxx'是无效的（除非该 script 是后续动态创建的，且你手动设了nonce并 append） - 真正起作用的只有两种方式：① SDK 初始化脚本本身是服务端渲染进 HTML 的内联脚本，并显式写了
nonce；② SDK 的 runtime 脚本通过模板注入，且你控制了它的<script>标签输出
为什么微信公众号里弹窗 SDK 总是白屏或报 Refused to execute inline script
这不是 SDK 问题，而是 nonce 链路在微信环境里断了三处：
- 微信内置浏览器对 CSP 响应头更敏感，如果响应头里
Content-Security-Policy缺失、被 Nginx 或 CDN 中间件覆盖、或大小写/空格不一致（比如'nonce-abc123 '多了个空格），整个 nonce 机制就失效 - 公众号文章页常走缓存（尤其是 CDN 或微信服务器缓存），导致服务端生成的 nonce 被静态化复用，第二次访问时脚本因 nonce 过期被拒
- 弹窗 SDK 的入口脚本（如
init.js）如果是通过<script src="...">加载的，它本身不依赖 nonce；但它的内联初始化代码（比如__wxSdkInit({ ... })）常被框架打包成内联形式，这部分若没带 nonce 就会被拦
Webpack/Vite 构建的弹窗 SDK 如何注入正确 nonce
构建工具默认不处理服务端动态 nonce，必须手动桥接。关键不是“让 SDK 有 nonce”，而是“让 SDK 的内联部分和页面共享同一个 nonce 上下文”。
- Webpack 用户：在 HTML 模板中，把服务端传入的
nonce注入为全局变量，例如window.__csp_nonce__ = ""；然后在 SDK 入口 JS 里，用__webpack_nonce__ = window.__csp_nonce__（必须在任何模块执行前） - Vite 用户：不能依赖
__vite__自动注入，需在vite.config.ts的build.rollupOptions.output.manualChunks中排除 runtime，再通过模板将 nonce 写入内联<script>标签，确保 SDK 的 HMR 和启动逻辑都在该标签内 - React/Vue SSR 场景下：弹窗 SDK 的初始化逻辑必须作为组件的一部分参与 SSR 渲染，而不是客户端单独
import——否则 hydration 后的脚本没有 nonce 上下文
strict-dynamic 不是可选项，是动态 SDK 的生死线
即使你给初始 <script nonce="xxx"> 加了 nonce，只要 SDK 后续用 eval、innerHTML 或 new Function() 执行代码，或者动态创建新 script 标签，这些行为默认仍被 CSP 拦截。
立即学习“前端免费学习笔记（深入）”；
-
'strict-dynamic'必须出现在 CSP 响应头的script-src里，且位置靠前（如script-src 'strict-dynamic' 'nonce-xxx' 'self'） - 它只放行“由已获许可脚本创建的子脚本”，也就是说：第一个带 nonce 的脚本可以调用
document.createElement('script')，只要它也设置了script.nonce = 'xxx'，就能执行 - 注意：
'unsafe-inline'和'strict-dynamic'互斥，开了后者就必须关掉前者，否则浏览器会忽略'strict-dynamic'
