Nginx层开启Gzip压缩最高效，需在http块配置gzip on、min_length 1024、comp_level 5、types含application/json等文本类型，并加gzip_proxied any和gzip_vary on以确保Node.js接口响应被正确压缩。
直接在 Nginx 层开启 Gzip 压缩是最高效的方式，无需修改 Node.js 代码或前端逻辑，就能显著压缩 HTML、CSS、JS、JSON 等文本类响应体，通常体积可减少 60%–90%，对 API 接口（尤其是返回大 JSON 的场景）效果尤为明显。
核心配置必须放在 http 块中
Nginx 的 gzip 指令只有写在 http{ } 全局块内，才能对所有 server（包括反向代理到 Node.js 的服务）统一生效。若只写在某个 server{ } 或 location{ } 里，容易遗漏 PHP、API 接口或静态资源。
- gzip on; —— 必须启用，否则全部无效
- gzip_min_length 1024; —— 小于 1KB 的响应不压，避免压缩后反而变大（如空响应、简单状态码）
- gzip_comp_level 5; —— 推荐值，压缩率与 CPU 开销较平衡；6 可进一步省体积，但需观察 Node 服务高峰期 CPU 是否承压
-
gzip_types 至少包含：
text/html application/json application/javascript text/css text/plain text/xml application/xml+rss image/svg+xml
特别注意：必须显式加上 application/json，否则 Node.js 返回的接口数据（如/api/users）不会被压缩
反向代理场景要加 gzip_proxied
Node.js 通常通过 proxy_pass 暴露给 Nginx，此时响应来自后端，Nginx 默认可能跳过压缩。需补充：
- gzip_proxied any; —— 对所有代理响应启用压缩（含 status=200/404/500）
-
gzip_vary on; —— 强制添加
Vary: Accept-Encoding响应头，防止 CDN 或浏览器缓存混淆（比如缓存了未压缩版，再给支持 gzip 的客户端返回） - gzip_http_version 1.1; —— 明确要求 HTTP/1.1 协议才启用，兼容性更稳（虽然现代环境基本都支持，但加了更保险）
验证是否真正生效
不要只看配置写了没，要实测响应头：
- 用 curl 检查接口：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/api/data
查看返回中是否有Content-Encoding: gzip和Vary: Accept-Encoding - 浏览器开发者工具 → Network → 点开某个 JSON 请求 → Headers → Response Headers → 确认上述两个头存在
- 对比大小：Response 标签页里看 “Size”（传输体积） vs “Content”（解压后体积），差值越大说明压缩越有效
哪些绝对不能压、哪些可以考虑压
压缩不是万能的，错误启用反而拖慢服务：
- 禁用压缩的类型：JPEG、PNG、GIF、MP4、PDF、WOFF2、ZIP —— 它们本身已是高压缩格式，再 gzip 几乎不减体积，纯耗 CPU
-
谨慎压缩的类型：如果 Node.js 接口返回的是已 base64 编码的图片字段（如大图转成字符串嵌入 JSON），整个 JSON 仍可压缩，但要注意后端是否做了流式响应；若响应是 chunked 且动态生成，确保 Nginx 缓冲区够用（
gzip_buffers 16 8k可作兜底） -
进阶建议：对超大导出接口（如报表 CSV/JSON >2MB），可让前端请求时加
Content-Encoding: gzip头并压缩请求体，后端（如 Express + compression middleware）配合解压，实现双向减负
