meta标签配置csp在绝大多数生产场景下无效，因浏览器仅解析http响应头中的content-security-policy字段，script-src等关键指令被静默忽略；真正生效必须依赖服务端响应头，并配合nonce或hash控制内联脚本。
meta 标签配置 CSP 安全策略在绝大多数生产场景下无效，尤其对 script-src、connect-src、frame-src 等关键指令完全被浏览器静默忽略——这不是写法问题，而是规范和实现层面的硬性限制。
为什么里的CSP经常“看起来生效”但实际拦不住外链脚本
常见错觉来源：加了 <meta http-equiv="Content-Security-Policy" content="script-src 'self'"> 后，控制台没报错、页面还能跑，就以为策略起了作用。其实：
- 浏览器压根不解析
meta中的script-src，它只检查响应头里的Content-Security-Policy字段 - DevTools 的 Security 面板显示 “No CSP header found”，但你没注意这个提示，反而误以为
meta是替代方案 - 部分低风险指令（如
img-src、base-uri）在少数浏览器里有弱支持，但行为不一致、不可靠 - 本地用
file://协议打开 HTML 时，CSP 全面关闭；Chrome 124+ 还直接禁掉meta中的script-src支持
哪些CSP指令能用勉强一试（但慎用）
仅限无执行上下文、不涉及资源加载决策的指令，且兼容性差：
-
default-src 'self'：可能影响部分资源回退逻辑，但无法阻止外链<script src></script> -
base-uri 'self'：可防<base href="http://evil.com">被注入，相对可靠 -
upgrade-insecure-requests：只在 HTTPS 页面中对运行时发起的请求（如fetch("http://...")）生效，对 HTML 中硬写的<img src="http://...?x-oss-process=image/resize,p_40">无用
所有这些都必须放在 最前面，且不能被 JS 动态插入；多个 meta[http-equiv] 时，浏览器通常只认第一个。
真正起效的CSP必须走HTTP响应头
服务端发的 Content-Security-Policy 响应头才是唯一可靠路径，且必须配合 nonce 或 hash 才能拦住内联脚本：
- Nginx 示例：
add_header Content-Security-Policy "script-src 'self' 'nonce-{random}'";，注意双引号包裹整条策略，内部单引号用于源关键字 - 开发期无后端？用
http-server -p 8080 --cors --headers headers.json模拟，headers.json里写"Content-Security-Policy": "script-src 'self' 'unsafe-inline'"（仅调试，上线必须删'unsafe-inline'） -
default-src 'none'是安全起点，但漏配任意指令（如img-src、style-src）会导致对应资源静默失败，控制台只报 CSP violation，不提示缺哪条
选nonce还是hash？别混用但得知道区别
两者目标一致：让内联脚本合法化，同时拒绝未授权的内联执行。
-
nonce：服务端每次响应生成新随机值（如abc123），HTML 中写<script nonce="abc123">...</script>，响应头配script-src 'nonce-abc123'；硬编码或复用 nonce 值等于形同虚设 -
hash：对脚本内容（不含<script></script>标签）做 SHA256 摘要，如sha256-BzLdO9X...，写进策略；适合构建时确定的静态内联脚本，动态拼接的无法预计算 - 两者可共存，但浏览器只匹配其一；没匹配上的脚本仍被拦截
CSP 的复杂点不在语法，而在策略与代码结构的强耦合——一个没配 font-src 的页面，字体可能直接不渲染；一个忘了 connect-src 的前端监控 SDK，上报请求会被静默丢弃。工程落地时，必须把 CSP 当作构建流程的一部分，而不是贴在 HTML 里就完事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
