内联脚本哈希值不能手算，因为sha-256哈希必须基于浏览器实际解析的原始字节流（含精确换行、空格、服务端渲染后的真实内容），而非肉眼所见代码；手算极易因标签处理、编码差异、模板变量未展开、换行符不一致或type属性忽略而失败。
内联脚本哈希值为什么不能手算
手算 sha256- 值几乎必然失败，核心在于哈希对象必须是**浏览器实际解析的原始字节流**，而非你肉眼看到的代码。常见错误包括：
— 对 <script>alert(1)</script> 整个字符串哈希（错！应只取 alert(1)）
— 本地用 echo "alert(1)" | shasum -a 256，但服务端模板渲染后实际插入的是 alert("${name}")（内容已变）
— IDE 自动格式化在脚本前后加了空格或 Windows 换行符 \r\n，而命令行工具默认按 \n 处理
— 忽略 type 属性： <script type="module">...</script> 和 <script>...</script> 视为不同内容，哈希不通用
构建时自动化生成 hash 的关键步骤
真正可行的路径是把哈希计算嵌入构建流程，在 HTML 渲染完成、发送给浏览器前一刻生成对应值。重点不是“怎么算”，而是“对谁算”：
— 提取每个 <script></script> 块的 textContent（不含标签），注意保留原始换行与空格
— 确保该内容已完全服务端求值：Django 模板中 {{ user.name }} 必须展开为真实字符串，不能留着未解析的 {{ }}
— 用 UTF-8 编码该字符串，再调用 SHA-256，最后 Base64 编码（无换行、无空格）
— 将结果注入 CSP 响应头或 <meta http-equiv="Content-Security-Policy"> 中，多个值用空格分隔
Node.js 构建脚本里怎么安全算 hash
直接用 crypto.createHash('sha256') 是可行的，但必须严格控制输入源：
— 不要用 fs.readFileSync(file, 'utf8') 读 HTML，它会丢 BOM、转换换行符
— 改用 fs.readFileSync(file)（二进制 Buffer），再用正则提取 <script>]*>([\s\S]*?)</script>，并确保捕获组未被贪婪破坏
— 对每个匹配到的脚本体，显式调用 new TextEncoder().encode(str) 转为 Uint8Array，再喂给 hash.update()
— Base64 编码必须用 .toString('base64')，不能依赖第三方 base64 库（可能加换行）
— 输出格式必须是 sha256-xxx=，且整个 CSP 字符串长度别超 1000 字符，否则浏览器截断
上线后哈希失效的典型表现和排查点
一旦哈希不匹配，浏览器只报 Refused to execute inline script，不指明哪条脚本、哪个哈希出问题。最容易被忽略的点：
— 构建产物 HTML 被 gzip 压缩后，某些 CDN 会自动注入统计脚本（比如百度统计），导致 DOM 中多出一个 <script></script> 块，但你的哈希列表没包含它
— 开发环境开了 'unsafe-inline'，上线忘了删，CSP 策略虽含 hash 但因 'unsafe-inline' 存在而整体失效
— 使用了 hx-get 或 hx-on 这类 htmx 内联指令，它们最终会动态生成 onclick 属性，这类脚本不属于 CSP 的 script-src 校验范围，hash 无效
— 浏览器 DevTools 手动编辑过 HTML，或插件注入了额外节点，导致实际执行的脚本和你计算哈希时的原始 HTML 不一致
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
