nginx 通过 gzip_static 直接返回预生成 .gz 文件实现高效静态资源压缩。构建阶段需生成同名 .gz 文件并保留源文件，nginx 在匹配 location 中启用 gzip_static，且 root 路径必须正确；验证需结合 content-encoding、content-length、etag 和 last-modified。
直接让 Nginx 返回预生成的 .gz 文件，而不是实时压缩，是实现静态资源响应体预压缩最有效的方式。它不消耗 CPU、TTFB 更低、响应更稳定，关键在于构建阶段产出文件 + Nginx 精准启用 gzip_static。
构建阶段：必须提前生成同名 .gz 文件
所有需压缩的静态资源（JS、CSS、HTML、SVG、JSON、字体等）在打包时就要输出对应的 .gz 文件，原始文件必须保留。
- Webpack 项目：用
compression-webpack-plugin，配置algorithm: 'gzip'和deleteOriginalAssets: false - Vite 项目：用
vite-plugin-compression，设algorithm: 'gzip'、ext: '.gz'，避免误删源文件 - 已上线补救：执行批量压缩命令
find /path/to/static -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" -o -name "*.json" -o -name "*.svg" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \;完成后再同步修改时间：
touch -r app.js app.js.gz，否则可能触发缓存异常或退化为动态压缩。
Nginx 配置：只在静态 location 块中启用 gzip_staticgzip_static on 不是全局开关，也不受 gzip_types 控制，它只在能准确映射磁盘路径的 location 块中生效，且优先级高于 try_files。
推荐写法：
location ~* \.(js|css|json|svg|woff2?|ttf|eot|html)$ {
root /usr/share/nginx/html;
gzip_static on;
}
注意：
- 不要写在
http或server顶层 - 不要与
try_files $uri混用在同一块里——否则.gz可能被跳过 -
root或alias必须存在，确保 Nginx 能拼出/static/app.js.gz的真实路径 - 无需重复写
gzip on或调整gzip_comp_level，这些属于兜底策略，与gzip_static各司其职
验证是否真正走预压缩路径
仅看 Content-Encoding: gzip 不够，需交叉验证：
- 用
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app.js获取响应头 - 检查
Content-Length是否等于本地app.js.gz的字节数（ls -l app.js.gz） - 查看
ETag是否由.gz文件的 inode + mtime 构成（原始文件的 ETag 格式不同） - 确认
Last-Modified时间戳与.gz文件的修改时间一致
若响应变慢，大概率是.gz缺失、路径不对，或时间戳未同步，Nginx 会多一次stat()后回退到动态压缩。
与其他压缩策略协同工作gzip_static 是主路径，gzip on 是兜底，两者可共存但职责分明：
- 在
http块中全局开启gzip on，并配好gzip_min_length 1024、gzip_types（务必含text/html）、gzip_vary off（避免 CDN 缓存分裂） -
.gz文件存在时，Nginx 直接返回；不存在时，才走gzip on动态压缩 - 已压缩格式（如 JPG、PNG、MP4、WOFF2）应在对应
location中显式写gzip off，防止白耗 CPU
