Nginx静态资源响应头应动态注入、批量配置、全站生效且可验证：用环境变量传Git版本号，正则location统一缓存策略，http块顶层加always设安全头，暴露自定义头需配CORS，最终以curl -I实测为准。
在 Nginx 中实现静态资源响应头的自动化注入，核心是把版本、缓存、安全等头信息与构建流程和运行时环境联动起来，而不是写死在配置里。关键不在于“加一行 add_header”，而在于让头内容可变、可验证、可继承且不被覆盖。
用环境变量动态注入业务版本号
硬编码版本号（如 add_header X-Biz-Version "v2.3.1"）无法反映真实部署状态。推荐在 CI/CD 构建阶段生成版本标识（Git commit hash、语义化 tag 或构建时间戳），通过环境变量传给 Nginx：
- 启动 Nginx 前，用 systemd 或容器环境注入：
env_biz_version=git-abc1234 - Nginx 配置中启用：
env env_biz_version;（放在 http 块顶部） - 在静态 location 中使用：
add_header X-Biz-Version $env_biz_version always;
这样每次发布，静态资源响应头里的版本号自动更新，前端上报或运维排查时能精准定位代码快照。
按路径或类型批量设置响应头，避免重复写
不用每个 location 都复制一遍缓存策略。优先用正则匹配统一管理同类资源：
- 所有带哈希的静态文件（
.js、.css、.woff2等）：用location ~* \.(js|css|woff2?|ttf|eot|svg)$，配add_header Cache-Control "public, max-age=31536000, immutable" always; - 图片类资源（
.png、.jpg、.webp）：单独一个 location，设Cache-Control "public, max-age=2592000"（30 天） - 未带哈希的 HTML 或模板页：用前缀匹配（如
location /pages/），设Cache-Control "no-cache, must-revalidate"
注意：正则 location 优先级高于普通前缀，建议把它放在配置靠后位置，避免误匹配。
全站安全头统一注入，确保 404/500 也生效
安全类响应头（如 X-Content-Type-Options、Strict-Transport-Security）必须覆盖所有响应状态码，包括错误页。最稳妥方式是在 http 块顶层集中配置：
- 加上
always参数：add_header X-Frame-Options "SAMEORIGIN" always; - 删掉所有
server或location里重复的安全头，防止覆盖或遗漏 - 验证时别只测首页——用
curl -I https://site.com/404-test和curl -I https://site.com/500-crash确认头依然存在
没加 always 的话，Nginx 默认只对 2xx/3xx 响应生效，这是线上常见漏洞点。
配合前端使用，注意跨域与读取限制
如果前端 JS 需要读取自定义头（比如做灰度判断或日志上报），有两个前提：
- 静态资源必须与主站同源；若走 CDN 或独立域名，需在响应头中显式声明：
add_header Access-Control-Expose-Headers "X-Biz-Version" always; - 同时配上 CORS 头：
add_header Access-Control-Allow-Origin "*" always;（生产环境建议精确域名） - 不要用该 header 控制资源加载逻辑——版本控制应靠 URL 路径（如
/static/app.a1b2c3.js）或 query（app.js?v=2.3.1），header 只作元数据用途
最后，每次改完配置，务必用 curl -I 实测真实响应，别只信配置语法检查。
