nginx对静态资源的“二次加工”实为零侵入、声明式的配置增强，包括：①gzip_static预压缩交付；②add_header/map响应头优化；③echo模块轻量注入；④proxy_pass缓存协同分发。
“对静态资源请求进行二次加工”这个说法容易引发误解——Nginx 本身不支持、也不应尝试对已压缩或已生成的静态文件做运行时修改（比如解压再重压、动态注入代码、实时转码等）。它不是应用服务器，没有执行逻辑的能力。所谓“二次加工”，在 Nginx 场景中实际指的是一系列**零侵入、声明式、基于配置的增强处理**，核心目标是：提升交付效率、保障内容正确性、适配客户端能力，而非真正意义上的“加工”。
用 gzip_static 实现无损预压缩交付
这是最常见也最关键的“加工”：让 Nginx 自动识别并返回同名 .gz 文件，同时设置正确的 Content-Encoding: gzip 响应头。
- 前端构建时生成 app.js.gz、style.css.gz 等（保留原始文件）
- Nginx 配置中只启用 gzip_static on;（禁用所有 gzip on 和 gzip_* 动态压缩指令）
- 请求 /static/app.js 时，Nginx 检查是否存在 /static/app.js.gz；存在则直接返回该文件，并自动加头；不存在则回退返回原始 app.js
通过 add_header 和 map 实现响应头增强
可在 location 块中安全添加或覆盖响应头，用于缓存控制、安全策略或客户端适配：
- 强制缓存策略：add_header Cache-Control "public, max-age=31536000, immutable";
- 跨域支持：add_header Access-Control-Allow-Origin "*";（仅限公开资源）
- 根据 Accept-Encoding 动态设 Vary：需配合 gzip_vary on;，确保 gzip 和非 gzip 版本被分别缓存
借助第三方模块实现轻量级内容注入
若确有极简动态需求（如插入版本号、环境标识），可引入 echo-nginx-module 这类轻量模块：
- 编译时通过 --add-module=/path/to/echo-nginx-module 加入
- 配置中使用 echo_before_body "$time_iso8601"; 在 HTML 响应体前插入时间戳
- 注意：仅适用于纯文本资源（HTML/JS/CSS），不适用二进制文件（图片、字体等）
用 proxy_pass + 缓存协同实现边缘层内容分发优化
当静态资源托管在远端源站时，Nginx 可在边缘节点完成“逻辑加工”：
- 设置 proxy_cache_key "$scheme$request_method$host$uri$is_args$arg_v$http_accept_encoding"，使不同编码格式缓存隔离
- 用 proxy_hide_header 屏蔽源站不必要头（如 Server、X-Powered-By）
- 用 proxy_set_header 补充标准化头（如 X-Forwarded-For、X-Real-IP）
