integrity校验失败时浏览器直接丢弃资源，不解析不执行，仅报“the resource was blocked because integrity check failed”等警告；根本原因是哈希值未匹配最终上线文件、缺失crossorigin属性、cdn未返回access-control-allow-origin头或url存在重定向。
integrity校验失败时浏览器直接丢弃资源
写了 integrity 但样式/脚本突然失效，控制台出现 The resource was blocked because integrity check failed 或 Failed to find a valid digest in the 'integrity' attribute —— 这不是加载慢，是浏览器主动扔掉了整个文件，连解析都不做。
常见诱因：哈希值没对应最终上线文件、漏写 crossorigin、CDN 返回头缺失 Access-Control-Allow-Origin、或用了带重定向的 URL（比如短链跳转后哈希失效）。
- 哈希必须基于压缩后、Babel 处理完、source map 剥离后的**最终上线文件**生成，本地开发版或未构建的源码算出来的值一定不匹配
-
integrity单独存在等于没写，必须和crossorigin成对出现；crossorigin="anonymous"最常用，但要求服务端返回Access-Control-Allow-Origin: * - 用
curl -I https://cdn.example.com/style.css检查是否返回 301/302；若有重定向，哈希校验必然失败——换 cdnjs、jsDelivr 等直达链接
如何生成正确的integrity值
手算容易出错，优先走构建流程自动化。核心三步：选算法 → 算哈希 → base64 编码 → 拼前缀。别复制别人页面里的值，哪怕 URL 相同，版本、压缩方式、BOM 字节都可能导致哈希不同。
命令行示例（Node.js 环境）：
cat style.css | openssl dgst -sha384 -binary | openssl base64 -A输出形如
sha384-o9K=，再拼成 sha384-o9K= 放进 integrity 属性。
- 优先用
sha384：比sha256抗碰撞更强，且 unpkg、jsDelivr 等主流 CDN 默认支持 - Webpack/Vite 可用插件自动注入，例如
vite-plugin-sri；CI 流水线里建议加一步校验产出文件哈希是否与预期一致 - 含动态内容（如环境变量、内联 CSS 变量）的文件，必须确保构建时已稳定替换，否则每次哈希都变，
integrity失效
校验失败后 fallback 要怎么写
单纯加 integrity 不解决可用性问题。浏览器丢弃资源后，页面可能白屏或功能异常，必须主动 fallback。
监听 error 事件捕获失败，再加载备用资源：
document.addEventListener('error', e => {
if (e.target.matches('link[rel=stylesheet]')) {
loadFallbackCSS();
}
});
- 这个监听必须在
里尽早注册，否则可能错过事件 -
loadFallbackCSS()应加载本地兜底文件，路径要稳定，避免又触发一次校验失败 - 漏掉
crossorigin会导致字体、CDN JS/CSS 的错误无法上报，console.error里看不到任何线索——这是最常被忽略的硬性依赖
为什么加了integrity反而让页面更不稳定
很多人以为加了就安全了，结果线上大面积白屏。根本原因是：没配对 crossorigin，或 CDN 不支持 CORS，或用了老旧镜像站。
- 模块脚本（
type="module"）默认启用 CORS，所以integrity必须搭配crossorigin，否则直接报错 -
crossorigin="use-credentials"需服务端明确返回Access-Control-Allow-Origin: https://yourdomain.com（不能是*），配置稍复杂，日常优先用anonymous - 某些 CDN（尤其内部镜像或小众节点）不返回 CORS 头，此时加
integrity+crossorigin会直接阻断加载——先确认 CDN 支持再启用
真正难的是权衡：校验带来安全性，但也引入额外失败路径。生产环境启用前，务必在真实网络条件（含弱网、跨域、CDN 节点）下验证 fallback 是否真能接管。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
