本文详解 Stripe v3 加载 hcaptcha-invisible 页面时触发的 CSP “Refused to execute inline script” 报错原因，指出其本质是服务端误配 Content-Security-Policy-Report-Only 响应头所致，并提供安全、合规的修复方案（禁用 Report-Only 模式、使用哈希白名单），避免滥用 'unsafe-inline'。
本文详解 stripe v3 加载 hcaptcha-invisible 页面时触发的 csp “refused to execute inline script” 报错原因，指出其本质是服务端误配 `content-security-policy-report-only` 响应头所致，并提供安全、合规的修复方案（禁用 report-only 模式、使用哈希白名单），避免滥用 `'unsafe-inline'`。
该错误看似发生在前端集成 Stripe 时，实则根源在服务端 Content Security Policy（CSP）的配置策略上。关键线索藏在报错信息末尾的 [Report Only] —— 这明确表明浏览器正在以只报告不阻断（Content-Security-Policy-Report-Only）模式执行策略，而非真正生效的 Content-Security-Policy。因此，即使你通过 <meta> 标签添加了宽松策略（如包含 'unsafe-inline'），它也无法覆盖或绕过已存在的 HTTP 响应头策略，因为浏览器要求所有 CSP 规则必须同时满足（“all policies must pass”）。
⚠️ 重要澄清：<meta http-equiv="Content-Security-Policy"> 无法作用于第三方资源（如 js.stripe.com 域下的 hcaptcha-invisible-*.html）。该 HTML 文件由 Stripe 服务器动态生成并返回，其执行环境受 Stripe 自身响应头控制，而非你的页面 <meta>。你在自己页面中设置的 CSP 只约束你域下加载的脚本、样式等资源，对跨域 iframe 或嵌入内容无管辖权。
真正需要排查和修改的是：你的后端服务器（或 CDN、反向代理如 Nginx/Apache）是否错误地为所有响应（包括 HTML 页面）设置了 Content-Security-Policy-Report-Only 响应头？ 例如：
Content-Security-Policy-Report-Only: script-src 'self';
✅ 正确做法是：
- 定位并移除 Content-Security-Policy-Report-Only 头，改用标准 Content-Security-Policy；
- 若需允许 Stripe 的特定内联脚本（如 hcaptcha-invisible 中的初始化代码），优先采用哈希白名单（Hash-based allowlist），而非 'unsafe-inline'：
Content-Security-Policy: script-src 'self' js.stripe.com 'sha256-CBu0w5uiOaPgb2R6Zgf7E0+STJHF4lcPIdhZzQXE6yk=';
该哈希值（sha256-...）已在报错信息中明确给出，对应 Stripe 当前版本中该内联脚本的精确内容。只要 Stripe 不更新该内联代码，此哈希即长期有效。若未来 Stripe 升级导致哈希失效，浏览器会再次报错并提示新哈希，便于及时更新。
❌ 错误尝试示例（应避免）：
- 在 <head> 中添加 <meta http-equiv="Content-Security-Policy" content="... 'unsafe-inline'">：既无效（不作用于 Stripe 资源），又严重削弱安全性；
- 试图在前端 JS 中动态注入 <script> 标签绕过：CSP 在解析阶段即拦截，JS 无法干预。
? 总结：该问题不是 Stripe 集成缺陷，而是 CSP 策略配置不当引发的误报/误阻。修复核心在于——统一策略入口（服务端响应头）、关闭 Report-Only 模式、对必要内联脚本使用哈希授权。这既保障了应用安全性，又确保了 Stripe 无感集成的稳定性。
