sri校验必须同时设置integrity和crossorigin属性才生效，仅写integrity会被静默跳过；仅和支持，哈希须基于线上实际响应体用sha384计算并base64编码。
integrity 和 crossorigin 必须成对出现才生效
只写 integrity 属性，浏览器根本不会启动校验——它会静默跳过，资源照常加载，控制台连 warning 都不报。常见现象是页面白屏、jQuery is not defined 或样式丢失，你却查不到 SRI 相关错误。
必须同时设置：
-
crossorigin="anonymous"：适用于 jsDelivr、cdn.jsdelivr.net、unpkg 等公开 CDN，请求不带 Cookie -
crossorigin="use-credentials"：仅当你自己的后端要求鉴权（如登录态）访问静态资源时使用，且服务端必须返回Access-Control-Allow-Credentials: true和明确的Access-Control-Allow-Origin（不能是*） - 别写
crossorigin=""：Chrome 里等价于anonymous，但 Firefox 解析更严格，可能直接忽略
漏掉或写错 crossorigin，SRI 就等于没开。
哈希值必须从线上 URL 实际响应体生成
本地文件、构建产物、甚至别人给的哈希值，只要和浏览器最终拿到的字节流不一致，SRI 就必然失败。CDN 可能重定向、返回 gzip/Brotli 压缩内容、加 BOM、或因 UA 返回不同版本——这些都会让哈希对不上。
用这条命令生成（模拟浏览器行为）：
curl -sL https://cdn.jsdelivr.net/npm/react@18.2.0/umd/react.production.min.js | openssl dgst -sha384 -binary | openssl base64 -A
关键点：
-
-sL：静默 + 跟随重定向，拿到浏览器实际加载的最终响应 -
-binary：对解压后的明文做哈希，和浏览器校验逻辑一致 -
-A：防止 base64 输出换行符，否则integrity值非法 - 算法优先选
sha384：比sha256抗碰撞更强，主流 CDN 全支持
只对 <script></script> 和 <link rel="stylesheet"> 生效
SRI 是 W3C 明确定义的机制，作用域非常窄。其他所有写法都不触发校验，写了也白费力气：
-
<img src="" integrity="">：完全忽略，不报错也不校验 -
<link rel="icon">或<link rel="preload">：不支持 -
document.createElement('script')后手动设src和integrity：浏览器不认，只校验 HTML 解析阶段的静态标签 - 内联脚本（
<script>console.log()</script>）：integrity属性无效 -
fetch()或<iframe></iframe>加载的资源：SRI 规范未覆盖
想保护图片、字体或动态加载资源？得靠 CSP 或服务端签名验证，SRI 不管这些。
CI/CD 中自动化注入 integrity 值
手工维护 integrity 值不可持续，尤其在频繁更新依赖的项目中。推荐在构建流程中自动计算并注入：
- Webpack：用
webpack-subresource-integrity插件，自动为script和link标签注入integrity，并强制要求crossorigin - Vite：配合
vite-plugin-sri，支持sha384和多 hash 算法 - 自定义脚本：在构建后扫描 HTML 中的
script[src]和link[rel="stylesheet"]，用curl -sL获取远程资源并生成哈希，再回填到 HTML
注意：如果 CDN URL 含 query 参数（如 ?v=123），确保该参数不影响实际响应体；否则缓存策略变化会导致哈希失效。真正难的不是算哈希，而是保证每次构建拿到的是同一份线上字节流——这需要和 CDN 运维对齐缓存规则与重定向策略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
