最有效的方式是让Nginx直接返回预生成的.gz文件。构建时需为JS、CSS等文本资源生成同名.gz文件且保留源文件；Nginx中在静态资源location块启用gzip_static on，并确保.gz文件与源文件同目录、时间戳同步；gzip_static与gzip on共存但职责分明，前者零CPU开销，后者作兜底。
最有效的方式不是让 Nginx 实时压缩，而是让它直接返回预生成的 .gz 文件——零 CPU 开销、TTFB 最低、压缩率更稳。
构建阶段必须产出 .gz 文件
所有文本类静态资源（JS、CSS、HTML、SVG、JSON、字体等）在打包时就要生成同名 .gz 文件，原始文件不能删。
- Webpack 项目：用
compression-webpack-plugin，设algorithm: 'gzip'和deleteOriginalAssets: false - Vite 项目：用
vite-plugin-compression，配置ext: '.gz'，避免误删源文件 - 已有部署补救：批量生成，例如
find /path/to/static -type f \( -name "*.js" -o -name "*.css" -o -name "*.html" \) -exec gzip -c9 {} \; -exec mv {}.gz {}\.gz \; - 关键细节：
.gz文件必须与源文件同目录；建议同步修改时间：touch -r app.js app.js.gz，否则可能触发缓存异常或退化为动态压缩
Nginx 配置要精准启用 gzip_static
gzip_static on 不是全局开关，只在能准确映射磁盘路径的 location 块中生效，且优先级高于 try_files。
- 正确写法（放在服务静态资源的 location 中）：
location ~* \.(js|css|json|svg|woff2?|ttf|eot|html)$ {<br> root /usr/share/nginx/html;<br> gzip_static on;<br>} - 不要写在
http或server顶层；不要和try_files $uri混用在同一块里——否则gzip_static不会触发 - 无需重复写
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时间戳与app.js.gz的修改时间一致 - 若响应变慢，大概率是
.gz缺失、路径不对，或时间戳未同步——Nginx 会多一次stat()系统调用后回退到动态压缩
gzip_static 和 gzip on 协同工作
两者推荐共存，但职责分明：
-
gzip_static处理已预压缩的静态资源，零 CPU 开销 -
gzip on作为兜底，处理 API 响应、未打.gz的旧资源、或后端透传内容 - 在
http块中全局开启：gzip on;<br>gzip_min_length 1000;<br>gzip_types text/html text/css application/javascript application/json text/xml application/xml;
务必包含text/html - 禁用
gzip_vary on：开启它会导致 CDN 缓存分裂；实际生产中更推荐关掉，靠 ETag 或 Cache-Control 控制缓存粒度
