SRI是子资源完整性机制，通过integrity和crossorigin属性校验外部CSS/JS等资源哈希值，防止CDN劫持或篡改；样式表需SRI因非同源加载同样面临中间人攻击风险。
什么是SRI，为什么样式表也需要它
SRI（Subresource Integrity）不是脚本专属机制。只要通过 <link rel="stylesheet"> 引入的外部 CSS 文件走的是非同源 HTTP/HTTPS 请求，就存在被中间人篡改的风险——比如 CDN 被劫持、缓存污染，导致样式异常甚至配合 XSS 注入恶意行为。浏览器支持 SRI 的前提是资源响应头不包含 Content-Security-Policy: require-trusted-types-for 'script' 类限制，且请求协议为 HTTPS（部分浏览器对 HTTP 样式表完全忽略 integrity 属性）。
给 <link> 添加 integrity 和 crossorigin 属性
只加 integrity 不生效。必须同时满足两个条件：integrity 值正确 + crossorigin 属性存在（值可为空或 "anonymous"）。"use-credentials" 仅在需要带 Cookie 时使用，但会禁用 SRI 校验（浏览器直接忽略 integrity）。
-
integrity 值必须是 Base64 编码的加密摘要，格式为 <hash-algorithm>-<base64-value>，常用 sha384（比 sha256 抗碰撞更强）
- 生成方式：下载 CSS 文件后本地执行
openssl dgst -sha384 -binary style.css | openssl base64 -A
-
crossorigin 必须显式写出，哪怕只是 crossorigin=""
<link rel="stylesheet" href="https://cdn.example.com/v1.2.0/main.css"
integrity="sha384-abc123...xyz789" crossorigin="">常见失败原因和调试方法
SRI 失败时浏览器静默丢弃该样式表（无控制台报错），只会留下一条 Failed to find a valid digest in the 'integrity' attribute 级别的警告，且只在 DevTools 的 Console 中以「warning」级别显示（默认可能被过滤掉）。
- 检查网络请求响应头是否含
Content-Encoding: gzip 或 br：SRI 校验基于解压后的原始字节，但若服务器返回压缩内容而你用未压缩文件算 hash，必然不匹配
- 确保下载用于计算 hash 的 CSS 文件与线上完全一致（注意 BOM、换行符、末尾空格）
- 避免使用构建工具自动生成的 URL（如含 query 参数的
?v=123），SRI 不校验 URL，只校验响应体；但若 CDN 缓存了不同版本，hash 就失效
- Firefox 对
crossorigin="" 解析更严格，建议统一写成 crossorigin="anonymous"
CDN 和构建流程中如何自动化维护
手动更新 integrity 值不可持续。CI/CD 中应把 hash 计算纳入构建步骤：
- Webpack：用
webpack-subresource-integrity 插件，自动注入 integrity 并要求 crossorigin
- Vite：启用
build.ssr 不相关，需借助插件如 vite-plugin-sri，或在 index.html 中用模板语法动态插入（需配合预构建脚本）
- 若用 raw HTML 部署，可用 Makefile 或 npm script 调用
curl -s <a href="https://www.php.cn/link/46a9b6b873977a7dff695ff369c54bbb">https://www.php.cn/link/46a9b6b873977a7dff695ff369c54bbb</a> | openssl dgst -sha384 -binary | openssl base64 -A 生成值并 sed 替换
integrity 不生效。必须同时满足两个条件：integrity 值正确 + crossorigin 属性存在（值可为空或 "anonymous"）。"use-credentials" 仅在需要带 Cookie 时使用，但会禁用 SRI 校验（浏览器直接忽略 integrity）。
-
integrity值必须是 Base64 编码的加密摘要，格式为<hash-algorithm>-<base64-value>，常用sha384（比sha256抗碰撞更强） - 生成方式：下载 CSS 文件后本地执行
openssl dgst -sha384 -binary style.css | openssl base64 -A -
crossorigin必须显式写出，哪怕只是crossorigin=""
<link rel="stylesheet" href="https://cdn.example.com/v1.2.0/main.css"
integrity="sha384-abc123...xyz789" crossorigin="">常见失败原因和调试方法
SRI 失败时浏览器静默丢弃该样式表（无控制台报错），只会留下一条 Failed to find a valid digest in the 'integrity' attribute 级别的警告，且只在 DevTools 的 Console 中以「warning」级别显示（默认可能被过滤掉）。
- 检查网络请求响应头是否含
Content-Encoding: gzip 或 br：SRI 校验基于解压后的原始字节，但若服务器返回压缩内容而你用未压缩文件算 hash，必然不匹配
- 确保下载用于计算 hash 的 CSS 文件与线上完全一致（注意 BOM、换行符、末尾空格）
- 避免使用构建工具自动生成的 URL（如含 query 参数的
?v=123），SRI 不校验 URL，只校验响应体；但若 CDN 缓存了不同版本，hash 就失效
- Firefox 对
crossorigin="" 解析更严格，建议统一写成 crossorigin="anonymous"
CDN 和构建流程中如何自动化维护
手动更新 integrity 值不可持续。CI/CD 中应把 hash 计算纳入构建步骤：
- Webpack：用
webpack-subresource-integrity 插件，自动注入 integrity 并要求 crossorigin
- Vite：启用
build.ssr 不相关，需借助插件如 vite-plugin-sri，或在 index.html 中用模板语法动态插入（需配合预构建脚本）
- 若用 raw HTML 部署，可用 Makefile 或 npm script 调用
curl -s <a href="https://www.php.cn/link/46a9b6b873977a7dff695ff369c54bbb">https://www.php.cn/link/46a9b6b873977a7dff695ff369c54bbb</a> | openssl dgst -sha384 -binary | openssl base64 -A 生成值并 sed 替换
Content-Encoding: gzip 或 br：SRI 校验基于解压后的原始字节，但若服务器返回压缩内容而你用未压缩文件算 hash，必然不匹配?v=123），SRI 不校验 URL，只校验响应体；但若 CDN 缓存了不同版本，hash 就失效crossorigin="" 解析更严格，建议统一写成 crossorigin="anonymous"
integrity 值不可持续。CI/CD 中应把 hash 计算纳入构建步骤：
- Webpack：用
webpack-subresource-integrity插件，自动注入integrity并要求crossorigin - Vite：启用
build.ssr不相关，需借助插件如vite-plugin-sri，或在index.html中用模板语法动态插入（需配合预构建脚本） - 若用 raw HTML 部署，可用 Makefile 或 npm script 调用
curl -s <a href="https://www.php.cn/link/46a9b6b873977a7dff695ff369c54bbb">https://www.php.cn/link/46a9b6b873977a7dff695ff369c54bbb</a> | openssl dgst -sha384 -binary | openssl base64 -A生成值并 sed 替换
真正容易被忽略的是：SRI 只验证传输完整性，不解决资源是否可信的问题。如果 CDN 本身被攻陷，它返回的仍是“完整但恶意”的 CSS——所以 SRI 必须和 CSP 的 style-src 配合使用，且优先信任内联关键 CSS，而非盲目依赖外部样式表。
