不支持sri的浏览器直接忽略integrity属性，资源照常加载执行，既不校验也不报错；老版本ie、android 4.4及更早webview等完全不识别该属性。
不会阻塞加载，也不会报错——不支持 SRI 的浏览器直接忽略 integrity 属性，资源照常下载执行。
不支持 SRI 的浏览器实际表现是什么
老版本 IE（全部）、Android 4.4 及更早 WebView、部分定制 ROM 的内置浏览器等，根本不识别 integrity 属性。它们遇到带该属性的 <script></script> 或 <link> 标签时，就像没看见一样，既不校验，也不拦截，更不会在控制台输出任何提示。
这意味着：你加了 integrity，对这些浏览器来说等于白加；但也不会因此导致资源加载失败或页面白屏。
为什么 crossOrigin 缺失会导致 SRI 失效甚至静默跳过
SRI 校验的前提是浏览器能拿到原始字节并独立计算哈希——而跨域资源默认受 CORS 限制，若没声明 crossorigin，浏览器无法读取响应体，也就无法校验。
-
crossorigin="anonymous"：不带凭据（cookies、auth headers），允许浏览器执行 SRI 校验；这是绝大多数 CDN 场景的正确选择 -
crossorigin="use-credentials"：带上凭据，但要求服务端明确返回Access-Control-Allow-Origin: https://your-site.com（不能是*）和Access-Control-Allow-Credentials: true，否则请求直接被 CORS 拦截，连下载都失败 - 完全不写
crossorigin：SRI 被跳过，资源照常加载，但失去完整性保护
哈希值生成错误是线上最常见的“假失败”原因
控制台报 Failed to find a valid digest in the ‘integrity’ attribute，90% 不是浏览器不支持，而是哈希算错了。
必须确保：
- 哈希基于资源**原始字节**计算，不是 UTF-8 文本渲染后的字符串
- 文件无 BOM、行尾符统一（LF 而非 CRLF）、无构建工具自动注入的 sourcemap 注释或 license header
- CDN 或代理层未做 gzip / brotli 压缩后再返回（SRI 校验针对解压前原始字节，但浏览器实际校验的是解压后内容 —— 所以必须确认 CDN 是否透传原始字节）
- 用
curl -s https://cdn.example.com/script.js | openssl dgst -sha384 -binary | openssl base64 -A这类命令本地验证，别依赖在线生成器
现代项目里最易被忽略的兼容盲区
真正危险的不是“不支持 SRI”的浏览器，而是“支持但配置错”的场景：比如把 crossorigin="use-credentials" 用在公共 CDN 上，结果因服务端没配对应 CORS 响应头，导致脚本 100% 加载失败——用户看到的就是白屏或功能缺失，且错误信息藏在 Network 面板里，不像控制台报错那么明显。
如果你的资源走的是自有后端（需登录态），那 use-credentials 是必须的，但务必同步检查服务端响应头；如果是公开 CDN，一律用 anonymous，并确保哈希与原始发布产物严格一致。
