sri校验必须同时设置integrity和crossorigin属性才生效，仅script和link[rel="stylesheet"]支持；缺失crossorigin会导致浏览器静默跳过校验，哈希值须基于线上url实际响应体（解压后明文）用sha384-base64生成。
HTML 文档结构本身不校验外部资源，真正起作用的是 integrity + crossorigin 组合，且只对 <script></script> 和 <link rel="stylesheet"> 生效——其他标签加了也白搭。
为什么写了 integrity 却没触发校验？
浏览器看到 integrity 属性后，会强制发起 CORS 请求，但若没配 crossorigin，就拿不到完整响应体，哈希比对直接跳过，integrity 被静默忽略。
-
crossorigin="anonymous"是公开 CDN（如 jsDelivr、cdn.jsdelivr.net）的标准写法，不带 Cookie -
crossorigin="use-credentials"仅用于需鉴权的私有静态资源，且后端必须返回Access-Control-Allow-Credentials: true和明确的Access-Control-Allow-Origin（不能是*） -
crossorigin=""在部分浏览器（如 Firefox）解析不稳定，建议统一用crossorigin="anonymous" - 控制台不会报“missing crossorigin”，只会安静加载资源，排查时容易误判
integrity 值怎么生成才和浏览器一致？
哈希必须基于目标 URL 实际返回的响应体计算，不是本地文件，也不是 HTML 中写的路径内容。CDN 可能重定向、压缩、加 BOM、甚至因 UA 返回不同版本，都会导致本地算的哈希失效。
- 推荐命令：
curl -sL https://cdn.example.com/app.js | openssl dgst -sha384 -binary | openssl base64 -A -
-sL确保跟随重定向并静默输出，模拟浏览器行为 -
openssl dgst -sha384 -binary对解压后的明文做哈希，和浏览器校验逻辑一致 - 算法优先选
sha384：比sha256抗碰撞更强，主流 CDN 默认支持 - 哈希值必须是 Base64 编码字符串，不能是 hex（比如不能写
sha256-abc123，得是sha256-AbCdEf）
哪些标签支持 SRI？哪些写了也无效？
SRI 是 W3C 明确定义的机制，只作用于两类标签：<script></script> 和 <link rel="stylesheet">。其他所有加载方式都不受保护。
-
<img src="" integrity="">：浏览器完全忽略，不校验也不报错 -
<iframe src=""></iframe>或fetch()动态加载：SRI 规范未覆盖，无法启用 -
document.createElement('script')并手动设置src和integrity：浏览器不校验，只认 HTML 解析阶段的静态标签 - 内联脚本（
<script>console.log()</script>）：integrity属性无效 -
<link rel="icon">、<link rel="preload">：不支持，写了等于没写
校验失败时会发生什么？怎么定位问题？
浏览器发现哈希不匹配，会直接丢弃该资源，不执行、不解析、不触发 onerror，控制台只报一句模糊警告：Failed to find a valid digest in the 'integrity' attribute。
- 这个错误不指明是哪个标签、哪条 URL 出问题，排查时容易卡住
- 建议逐个检查含
integrity的<script></script>和<link>标签 - 打开 DevTools 的 Network 面板，确认对应请求是否返回 200，响应头是否含
Content-Encoding: gzip或br（SRI 校验基于解压后明文） - 用
curl -I检查响应头是否含Access-Control-Allow-Origin，否则 CORS 请求失败，校验根本不会启动
真正难处理的不是怎么写，而是“字节级一致性”——后端签名原文格式、前端取原始内容的方式、编码与换行符处理，三者稍有偏差，验证就失败。多数人卡在第一步，以为加了属性就万事大吉，其实连校验都没跑起来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
