SRI校验失效的主因是未配crossorigin属性或哈希值非源自线上实际响应体；必须同时设置integrity和crossorigin="anonymous"（公开CDN）或"use-credentials"（鉴权场景），且仅script和link[rel=stylesheet]支持。
加了 integrity 却没拦住被篡改的脚本？大概率是 crossorigin 没配，或者哈希值根本不是从线上 URL 实际响应体算出来的。
为什么只写 integrity 会静默失效
浏览器看到 integrity 属性后，会强制走 CORS 请求流程——但前提是显式声明 crossorigin。不写、写错值、或服务端没返回对应 CORS 响应头，校验就压根不会启动。
-
crossorigin="anonymous"是绝大多数 CDN 的正确写法（如cdn.jsdelivr.net、code.jquery.com），它发起无凭据请求，要求服务端返回Access-Control-Allow-Origin: * -
crossorigin="use-credentials"仅当你自己的后端要求带 Cookie 加载资源时才用，且必须配套返回Access-Control-Allow-Credentials: true和明确的Access-Control-Allow-Origin（不能是*） - 只写
crossorigin=""在 Chrome/Firefox 中等价于anonymous，但 Firefox 解析更严格，建议统一写成crossorigin="anonymous" - 控制台不会提示“你漏了
crossorigin”，只会安静跳过 SRI，页面白屏时很难定位
哈希值必须从真实 URL 响应体生成
本地下载的 .js 文件、构建产物、甚至复制粘贴的别人家哈希，只要和浏览器实际请求到的内容字节不一致，SRI 就必然失败。
- CDN 可能返回 gzip 或 Brotli 压缩内容，但浏览器校验的是解压后的明文——用
curl -sL跟随重定向并自动解压，再哈希，行为才一致 - 命令示例：
curl -sL https://cdn.example.com/react.min.js | openssl dgst -sha384 -binary | openssl base64 -A - 注意末尾的
-A：防止base64输出换行符，否则integrity值非法 - 在线生成器（如 srihash.org）底层也是
curl，但无法控制重定向链、编码细节或 BOM 头，出问题时难复现
哪些标签支持 SRI，哪些写了也白写
SRI 是 W3C 明确定义的机制，只对两类标签生效：<script></script> 和 <link rel="stylesheet">。其他所有情况，浏览器直接忽略 integrity 属性，不报错也不校验。
立即学习“前端免费学习笔记（深入）”；
-
<img src="" integrity="" alt="HTML script标签的integrity属性？资源完整性校验SRI" >：完全忽略，连 warning 都没有 -
<link rel="icon">、<link rel="preload">：不支持，SRI 规范未覆盖 -
document.createElement('script')后手动设置src和integrity：浏览器不校验，只认 HTML 解析阶段的静态标签 -
fetch()、import()、<iframe></iframe>：SRI 机制不介入，需靠 CSP 或其他手段防护
SRI 失败时浏览器怎么处理
校验失败不是抛异常或触发 onerror，而是直接丢弃资源，连解析都不做——这意味着脚本不执行、样式不应用，且没有回调可捕获。
- 控制台只报一条模糊警告：
Failed to find a valid digest in the 'integrity' attribute，级别为 warning，默认可能被过滤掉 - 多个哈希写在同一个
integrity属性里（如sha256-xxx sha384-yyy），浏览器从左到右尝试，第一个匹配就停，后面不校验；若缓存中残留旧版资源，而你只更新了右侧哈希，仍会失败 - 样式表失败时页面可能只是“看起来不对”，比脚本失败更难察觉——务必打开 DevTools 的 Network 面板，逐个检查带
integrity的请求是否返回 200 且 MIME 类型正确（text/css或application/javascript）
真正容易被忽略的是：SRI 不是“加了就安全”，而是“配错就等于没加”。crossorigin 缺失、哈希来源不对、标签类型不支持——这三类问题占 SRI 失效案例的 90% 以上，且全都静默发生。
