最简单有效的全站gzip压缩方案是在web服务器层（如nginx http块）统一配置：开启gzip、设置最小长度1024、压缩等级6、显式声明text/html等可压缩mime类型、启用gzip_vary和gzip_proxied，并避开php冲突、重复压缩及误压图片等陷阱。
直接在 Web 服务器层启用 gzip 压缩，是最简单、覆盖全站、无需改业务代码的方式。关键不是“开了就行”，而是让压缩只作用于该压的文本资源（HTML/JS/CSS/JSON/SVG），跳过图片、字体、视频等已压缩格式，并避开常见静默失效点。
确认客户端是否触发压缩协商
服务器不会主动压缩，必须收到 Accept-Encoding: gzip 请求头才启动：
- 现代浏览器默认携带该头，通常无需操作
- API 调用或旧版移动端 SDK 可能省略，需手动添加请求头
- CDN 或负载均衡器若剥离了该头，压缩会静默失效；可用
curl -H "Accept-Encoding: gzip" https://yoursite.com或浏览器 DevTools 的 Network 面板验证请求头是否存在
Nginx 全局配置（推荐写在 http 块）
这是最稳妥、统一生效的方式，覆盖静态文件、PHP、Node.js、JSON 接口等所有响应：
- gzip on; —— 必须开启
- gzip_min_length 1024; —— 小于 1KB 的响应跳过（避免压缩后反而变大）
- gzip_comp_level 6; —— 压缩率约提升至原始体积的 25%～35%，CPU 开销可控；设为 9 仅多省 3%～5%，但耗时翻倍
-
gzip_types text/html application/json application/javascript text/css application/xml image/svg+xml; —— 显式列出要压的 MIME 类型；
text/plain、application/x-httpd-php等也建议加入，尤其对 PHP 动态输出 -
gzip_vary on; —— 自动加
Vary: Accept-Encoding响应头，确保 CDN 和代理缓存区分压缩/未压缩版本 - gzip_proxied any; —— 允许对反向代理转发来的请求也压缩（适配常见架构）
避开几个高频失效陷阱
配置写对了，但没生效？大概率卡在这几处：
- 后端脚本（如 PHP）手动设置了
Content-Encoding: identity或Vary: *（不含Accept-Encoding），会导致 Nginx 拒绝压缩 - PHP 同时启用了
zlib.output_compression = On，与 Nginx gzip 冲突，应关闭 PHP 层压缩 - 构建时已生成
app.js.gz，又同时开了gzip_static on和gzip on，可能造成重复压缩或响应异常 - 误把
.jpg、.png、.woff2加进gzip_types：它们本身已是高压缩格式，再套 gzip 反而增大 10%～30% 体积
上线后必须实测验证
不能只看配置有没有保存，要查真实响应：
- 打开浏览器 DevTools → Network → 刷新页面 → 找一个 JS 或 JSON 请求
- 检查响应头中是否有
Content-Encoding: gzip - 对比右侧两列：Size（传输大小）应明显小于 Content（解压后大小），差值即为节省量
- 顺带确认
Vary: Accept-Encoding是否存在，否则缓存层可能出错
