sri校验由浏览器执行，nginx仅需正确提供资源、透传cors头（如access-control-allow-origin）、禁用动态压缩与响应重写，并配合前端构建注入integrity值。
Subresource Integrity（SRI）本身不由 Nginx 执行校验，而是由浏览器在加载外部脚本或样式时自动验证 integrity 属性是否匹配资源实际哈希值。Nginx 的作用是正确提供带哈希签名的资源、透传必要响应头，并避免破坏 SRI 有效性——比如不擅自压缩、不改写内容、不拦截跨域请求。
确保资源可被浏览器校验
SRI 要求资源支持 CORS，否则浏览器会因跨域限制拒绝校验。若资源托管在 Nginx 上（如 CDN 或静态服务），需显式返回 Access-Control-Allow-Origin：
- 对 JS/CSS 等子资源 location 块中添加：
add_header Access-Control-Allow-Origin "*";
（生产环境建议精确指定域名，如"https://your-app.com"） - 若资源需携带凭据（如 cookies），则还需加：
add_header Access-Control-Allow-Credentials "true";
并确保前端请求设置credentials: 'include' - 配合 CSP 使用更稳妥：
add_header Content-Security-Policy "require-sri-for script style;";
该策略强制所有<script></script>和<style></style>标签必须含integrity属性，否则直接阻止加载
避免破坏 SRI 完整性
动态压缩、重写响应体、添加内联内容等操作会导致资源哈希失效，SRI 校验失败后浏览器将丢弃资源：
- 禁用对已预压缩文件的实时压缩：
删掉gzip on或brotli on对静态资源的全局启用；改用gzip_static on;和brotli_static always;，只服务磁盘上存在的.gz/.br文件 - 不要在响应中注入 HTML、JS 或修改响应体（例如用
sub_filter替换文本），尤其不能用于带 SRI 的资源 - 确保资源 URL 稳定且带哈希指纹（如
app.a1b2c3.js），配合Cache-Control: public, immutable，防止浏览器缓存旧哈希对应的新内容
生成并注入 integrity 值（前端构建阶段）
Nginx 不生成 SRI 值，但需确保前端构建工具正确输出并写入 HTML：
- Webpack：用
HtmlWebpackPlugin+webpack-subresource-integrity插件自动注入 - Vite：启用
build.sourcemap并配合插件如vite-plugin-sri - 手动计算示例（以 SHA384 为例）：
openssl dgst -sha384 -binary vendor.js | openssl base64 -A
结果拼为：sha384-xxx...，填入<script integrity="sha384-xxx..."></script>
验证是否生效
部署后检查三点：
- 资源响应头含
Access-Control-Allow-Origin - HTML 中对应标签有
integrity和crossorigin（如<script crossorigin integrity="..."></script>） - 浏览器开发者工具 → Network → 该资源响应状态为 200，无“Blocked”提示；若故意篡改哈希，应看到控制台报错 “The resource…has an integrity mismatch”
