integrity属性对有效，但必须同时满足integrity值正确和crossorigin属性存在（推荐crossorigin="anonymous"），否则浏览器静默丢弃css且仅记录warning日志；哈希须基于cdn真实响应体计算，仅sha384等算法有效。
直接说结论：integrity 属性对 <link rel="stylesheet"> 有效，但必须同时满足两个硬性条件：哈希值正确 + crossorigin 属性存在；漏掉任一，浏览器就静默丢弃样式表，连报错都没有。
为什么加了 integrity 却没生效？
最常见原因是没写 crossorigin。浏览器只对 CORS-ineligible 请求（比如默认的 <link> 加载）跳过 SRI 校验——哪怕你写了 integrity，它也当不存在。
-
crossorigin="anonymous"是推荐写法，Firefox 解析更稳；crossorigin=""效果相同但兼容性略弱 -
crossorigin="use-credentials"会彻底禁用 SRI，哪怕哈希完全正确也无效 - 检查 Network 面板里该 CSS 请求的 Response Headers：必须有
access-control-allow-origin: *（或具体域名），否则跨域请求本身就会失败，SRI 更无从谈起
如何生成靠谱的 integrity 值？
别用本地文件直接算 hash。CDN 实际返回的内容可能被 gzip/brotli 压缩、带 BOM、含重定向、甚至因 query 参数缓存不同版本——这些都会让本地算出的哈希失效。
- 用线上真实响应体计算：
curl -sL https://cdn.example.com/style.css | openssl dgst -sha384 -binary | openssl base64 -A - 结果拼成
sha384-<base64></base64>格式，注意去除命令输出中的多余空格和换行 - 优先用
sha384，比sha256抗碰撞更强；禁用sha1和md5 - 如果 CDN 返回
Content-Encoding: gzip，你却拿未解压的原始文件算 hash，必然不匹配
构建流程中怎么避免手动维护 integrity？
人工更新哈希值不可靠，尤其当 CSS URL 含 hash 后缀（如 main.a1b2c3.css）或 query（如 ?v=2.1.0）时，URL 变了但哈希没重算，SRI 就形同虚设。
- Webpack 用户直接用
webpack-subresource-integrity插件，它会自动注入integrity并强制加上crossorigin="anonymous" - Vite 或 esbuild 需在构建后 hook：下载产出 CSS → 计算 SHA-384 → 替换 HTML 中对应
<link>的integrity和crossorigin - CI/CD 流程里务必把 hash 计算作为必跑步骤，而不是发布前“顺手补一下”
最容易被忽略的点是：SRI 失败时浏览器只记一条 warning 级日志 Failed to find a valid digest in the 'integrity' attribute，且默认被 Console 过滤掉。页面样式错乱却找不到原因，八成是它在作祟。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
