在真实生产环境中不能可靠防御内联xss，也不适合企业级系统；因其流式解析导致前置恶意脚本在策略注册前执行，且不支持动态nonce、report-to、frame-ancestors等关键指令，易被响应头覆盖或浏览器忽略。
直接说结论：<meta http-equiv="Content-Security-Policy"> 在真实生产环境中**不能可靠防御内联 XSS**，也不适合企业级系统。它只在极少数受限场景下“看起来有效”，但极易被绕过或完全失效。
为什么写CSP几乎拦不住<script>alert(1)</script>
浏览器解析 HTML 是流式的：只要恶意脚本出现在 <meta> 标签之前（比如 开头、 里靠前位置），它就会在 CSP 策略注册前立刻执行。
- 本地用
file://打开 HTML 文件时，所有浏览器都禁用 CSP ——<meta>完全不生效 - 只要服务端返回了任意
Content-Security-Policy响应头（哪怕拼错成Conten-Security-Policy），<meta>就被彻底忽略 - Safari 16.4 之前版本不支持
nonce-或sha256-指令在<meta>中生效 - Chrome 124+ 已明确忽略
script-src 'unsafe-inline'在<meta>中的写法 —— 写了等于没写
script-src 'self' 并不禁止内联脚本
script-src 'self' 只约束 <script src="..."></script> 的来源，它**默认允许所有内联脚本执行**，包括：<script>fetch('/api')</script>、<button onclick="xss()"></button>、<svg onload="xss()"></svg>。
- 真正起作用的是显式排除机制，比如
script-src 'self' 'unsafe-inline'—— 但加了这句就等于主动放行全部内联脚本 -
nonce-需服务端每次生成唯一值并同步注入到 HTML 和<meta>中；Safari / Android WebView 大部分版本根本不认这个语法在<meta>里 -
sha256-要提前计算哈希并硬编码；Webpack 若没开contenthash，构建后哈希就变，策略立即失效
什么情况下可以勉强用？
仅限以下三个条件同时满足的静态页面场景：
- 托管在不支持响应头修改的平台（如 GitHub Pages、Netlify 默认无 CSP 响应头）
- 页面完全不含动态内联脚本（无
onclick、无<script></script>块、无模板插值渲染） - 不需要
report-to、frame-ancestors、base-uri等关键指令（这些在<meta>中已被主流浏览器废弃）
示例写法（仅作示意，勿直接复制上线）：<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data:;">
真正要防住内联 XSS，必须用服务端响应头 + default-src 'none' + 显式拒绝 'unsafe-inline' 和 'unsafe-eval'；<meta> 无法注入动态 nonce，也无法上报违规行为——这些不是配置技巧问题，是浏览器设计层面的限制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
