integrity 属性仅在 crossorigin 配置正确、哈希算法匹配、文件内容精准对应且限于 script/link 标签时生效；漏配 crossorigin、哈希错误、动态加载未手动校验或 MIME 类型不符均导致校验失败。
integrity 属性本身不提供“自动安全防线”，它只在你配对正确、资源可控、构建流程闭环的前提下才起作用；漏掉 crossorigin、用错哈希算法、或加载动态子资源时不做手动校验，等于没开锁。
为什么加了 integrity 还报 The resource was blocked because integrity check failed
这不是浏览器故意刁难，而是校验链上某个环节断了。常见断点有：
-
crossorigin属性缺失或值错误（必须是anonymous或use-credentials，不能留空或写错大小写） - 服务端没返回
Access-Control-Allow-Origin响应头（尤其自建 CDN 或内网静态资源服务） - 哈希值不是对**最终上线文件**计算的——比如本地开发时用未压缩版生成，上线却用了 Uglify/Terser 压缩后的版本
- 用了
sha256-前缀但实际文件是用sha384算的，或者 base64 编码时多/少了一个=
integrity 只对 <script></script> 和
别指望它能保护 、 或内联脚本。浏览器压根不解析这些标签的 integrity 属性，写了也白写。
更关键的是：它不校验脚本运行时行为。比如你用 import('./chunk.js') 加载模块，或脚本里调用 fetch('/api/config.json')，这些后续请求完全脱离 integrity 控制范围。
所以真正要防住供应链攻击，得配合：
- 构建时生成 SRI 清单（如 Vite 的
vite-plugin-sri） - 动态加载前手动
fetch+ 哈希比对 +Blob注入 - 后端 API 返回子资源 URL 时，一并透出
integrity字段供前端校验
fetch() 的 integrity 选项不是“全能开关”
它只在满足两个硬性条件时才触发校验：
-
mode必须设为"cors"（"no-cors"下会被浏览器静默忽略） - 响应 MIME 类型必须属于可信任类型，如
text/javascript、application/javascript、text/css；返回application/json就不校验
而且它只校验当前响应体，不会递归检查该 JS 文件里 import 的其他模块。例如：
fetch('/js/main.js', { integrity: 'sha384-xxx', mode: 'cors' })
这段代码只保 main.js 没被篡改，不管它里面写的 import('./utils.js') 是不是安全的。
生成哈希值时最容易踩的三个坑
手动生成 integrity 值看似简单，实操中高频翻车点就三个：
- 用
cat file.js | openssl dgst -sha256 -binary | openssl base64 -A时，忘了加-A（否则换行符会混进 base64 字符串） - 哈希算法选
sha256—— 它抗碰撞能力弱于sha384，且部分老旧 CDN（如某些私有 Nginx 配置）默认不支持sha256校验 - 把构建产物路径搞错：Webpack/Vite 默认输出带 hash 的文件名（如
main.a1b2c3.js），但你生成哈希时却用了main.js，结果永远不匹配
真正稳定的方案是让构建工具自动注入：Vite 用 vite-plugin-sri，Webpack 用 webpack-subresource-integrity，避免人肉搬运哈希。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
