直接回答：CSP 是浏览器层面的白名单防线，通过响应头声明页面允许加载和执行的资源来源，主要价值是缓解 XSS 的利用：即使攻击者注入了脚本，内联脚本被禁、外源脚本域不在白名单也加载不了。它不能修复 XSS 漏洞本身（输出编码仍是根治），但能把大量注入变成无害文本。附加收益：防点击劫持（frame-ancestors）、强制 HTTPS 资源（upgrade-insecure-requests）、限制表单提交目标。
展开解析：有效配置的关键在 script-src：禁用 unsafe-inline 是分水岭——之后内联脚本和事件属性全失效，注入型 XSS 大半缴械；自己的内联脚本改用 nonce（每次响应随机）或 hash 白名单。'strict-dynamic' 让可信脚本动态加载的子脚本自动可信，适配现代前端构建。落地路线务必渐进：先 Content-Security-Policy-Report-Only 收集违例报告，清理存量内联代码与第三方域，再转强制执行；用 default-src 'self' 做基底逐项放开，object-src 'none'、base-uri 'none' 这种收口别漏。常见误伤：第三方统计/客服脚本频繁换域、浏览器扩展注入、老代码的 javascript: 链接。report-uri 报警接入监控，CSP 违例本身也是攻击情报。
追问方向：nonce 与 hash 的取舍？strict-dynamic 为什么能简化白名单维护？CSP 对 JSONP 的影响？
（约 450 字）