怎么在Nginx中实现静态资源响应头的自动化注入

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 实测真实响应，别只信配置语法检查。