应使用服务端HTTP响应头而非meta标签配置CSP，因meta CSP存在解析滞后、浏览器兼容性差、无法阻止内联脚本执行、易被响应头覆盖等问题，真实生产环境中基本无效。
别用 <meta http-equiv="Content-Security-Policy"> 防 XSS —— 它在真实生产环境里基本拦不住，还容易让你误以为“已经配好了”。
为什么 <meta> 的 CSP 几乎不拦内联脚本
浏览器解析 <meta http-equiv="Content-Security-Policy"> 是同步但滞后的行为：它必须等 HTML 解析到该标签位置才开始生效。而 <script>alert(1)</script> 或 <button onclick="..."> 这类内联代码，在解析到对应标签时就立刻尝试执行了 —— 此时 CSP 还没加载、没注册、没起效。
- Safari 16.4 之前版本会直接跳过含
nonce-或sha256-的整条script-src指令 - Chrome 124+ 已移除对
script-src 'unsafe-inline'在<meta>中的解析支持（写了也当没写） - 只要服务端返回了任意
content-security-policy响应头（哪怕只是空值或拼写错误），<meta>就被完全忽略 - 本地用
file://打开 HTML 时，CSP 全面关闭 ——<meta>和响应头都无效
script-src 'self' 写在 <meta> 里等于没设
你写 content="script-src 'self'"，本意是只允许同源 JS，但它根本无法阻止 <script>fetch('/api/user').then(r => r.json().then(console.log))</script> 这种内联脚本执行 —— 因为 'self' 只约束外部 <script src=""> 的来源，不约束内联脚本本身是否允许运行。
- 真正禁用内联脚本，必须显式排除；要拦住它，得靠
nonce-或hash-，而这两者在<meta>中不被 Safari / Android WebView 等主流环境可靠支持 - 写了
script-src 'self' 'unsafe-inline'更糟：等于主动放行所有onclick、onerror、<script>，XSS 防御形同虚设 - 就算侥幸生效，它也只作用于当前 HTML 文档，无法覆盖
iframe、worker、fetch子请求等上下文
真要上简版硬防御，必须走响应头 + 最小化指令
放弃 <meta>，改用服务端 HTTP 响应头发一条最简但有效的策略，才能真正阻断多数 XSS 载荷执行。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置示例（放在
server或location块中）：add_header Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; form-action 'self'; base-uri 'self'; frame-ancestors 'none'; object-src 'none'";
-
default-src 'none'是关键：它让所有未显式声明的资源类型（如img-src、style-src）全部失效，避免漏配导致宽松回退 - 必须配合前端改造：把所有内联脚本抽成外部文件，删掉
onclick、onerror等事件属性，否则策略一加，功能直接崩
最容易被忽略的是：CSP 不是“配完就安全”，而是“配错就失效”。尤其在已有复杂前端架构的项目里，Webpack/Vite 自动生成的内联代码、第三方 SDK 的脚本注入、甚至构建产物里的 data: URI，都可能绕过你以为严密的策略。
