integrity属性仅对<script>和<link>有效，需配合crossorigin使用，哈希值须为base64编码且基于最终上线文件生成，浏览器按从左到右顺序校验多个哈希并仅采用首个匹配项。
integrity 属性只对 <script> 和 <link> 有效
它不是通用校验机制，不能用在 <img>、<iframe> 或内联脚本里。浏览器只会在下载外部 JS/CSS 文件时触发哈希比对，一旦发现 integrity 值与实际内容不匹配，就直接丢弃该资源，连解析都不做。
常见错误现象包括：样式突然失效、第三方库报 TypeError: xxx is not a function、控制台出现 Failed to find a valid digest in the 'integrity' attribute 或 The resource <url> was blocked because integrity check failed</url>。
- 必须配合
crossorigin使用，否则浏览器跳过校验（哪怕写了integrity） - CDN 返回的响应头必须含
Access-Control-Allow-Origin，否则资源加载失败 - 哈希值必须是 base64 编码后的字符串，不能是原始 hex（比如不能写
sha256-abc123...而不转 base64）
生成正确 integrity 值的三个关键步骤
手算容易出错，但工具链支持已很成熟。核心是：选算法 → 算哈希 → base64 编码 → 拼前缀。
- 优先用
sha384：比sha256更抗碰撞，且主流 CDN（如 unpkg、jsDelivr）默认支持 - 文件必须是最终上线版本——压缩、Babel、source map 都会影响哈希结果
- 命令行示例（Node.js）：
cat jquery.min.js | openssl dgst -sha384 -binary | openssl base64 -A
，输出形如sha384-o9K...= - 在线工具推荐用官方 SRI Hash Generator，避免用那些不声明算法或自动补全错误前缀的野鸡工具
integrity + crossorigin 的组合行为容易被忽略
很多人以为加了 integrity 就安全了，其实没配对 crossorigin，等于没开锁。
-
crossorigin="anonymous"：最常用，不带 cookie，要求服务端返回Access-Control-Allow-Origin: * -
crossorigin="use-credentials"：带 cookie，需服务端明确返回Access-Control-Allow-Origin: https://yourdomain.com（不能是*） - 如果 CDN 不支持 CORS（比如某些老旧镜像站），加了
integrity反而让资源加载失败，页面白屏或功能缺失 - 模块脚本（
type="module"）默认启用 CORS，所以integrity必须搭配crossorigin，否则报错
多个哈希值怎么写？浏览器只认第一个匹配项
你可以提供多个哈希（比如同时支持 sha256 和 sha384），用空格分隔：
<script src="lib.js" integrity="sha256-xxx sha384-yyy" crossorigin="anonymous"></script>
但注意：浏览器按从左到右顺序尝试，只要第一个通过就停，不会继续校验后面的。所以要把最可能匹配的放前面；若旧版资源还在缓存中，而你只更新了后面那个哈希，校验仍会失败。
真正需要多哈希的场景极少——除非你在灰度发布不同构建产物，且无法统一哈希算法。日常开发中，固定一种算法、每次构建重算一次更稳妥。
复杂点在于：哈希值本身是构建产物的一部分，必须纳入 CI/CD 流程自动生成并注入 HTML，硬编码极易过期。最容易被忽略的是，本地开发时用的 dev server 通常不提供完整哈希，导致测试环境一切正常，上线后突然失效。
