gzip模块本身不节省带宽，真正节省靠HTTP响应阶段对HTML/JS/CSS/JSON等文本资源实时压缩，需严格限定MIME类型、设最小阈值（如1024字节）、选用compresslevel=6，并配合Cache-Control与ETag提升缓存复用率。
用 Python 的 gzip 模块本身不能“实现带宽节省”，它只是压缩工具；真正节省带宽，靠的是在 HTTP 响应阶段，对文本类资源（如 HTML、JS、CSS、JSON）做实时压缩，并确保浏览器能正确解压复用。关键不在调函数，而在服务端集成、类型控制、级别选择和缓存协同。
只对可压缩的文本资源启用 gzip
压缩不是越多越好，错误地压图片、字体、视频等二进制文件，反而增大体积、浪费 CPU。必须严格限定 MIME 类型：
- 必压：text/html、text/css、application/javascript、application/json、text/xml、application/xml、image/svg+xml
- 禁压：.jpg、.png、.webp、.woff2、.mp4、.pdf 等已高压缩格式
- 小文件跳过：设置最小阈值（如 1024 字节），避免为几十字节响应开销反超收益
压缩级别设为 6，兼顾效率与效果
gzip.compress(data, compresslevel=6) 是生产环境最稳妥的选择：
- level=1～3：CPU 轻，但压缩率提升有限，适合超高并发低延迟场景
- level=6（默认）：文本类资源压缩率约 65%，CPU 占用温和，响应延迟可控
- level=9：压缩率仅比 level=6 高 3%～5%，但 CPU 耗时翻倍以上，不推荐全量使用
配合 HTTP 缓存与 ETag 提升复用率
单次压缩省不了多少带宽，持续节省靠缓存：
- 对压缩后响应设置
Cache-Control: public, max-age=31536000，尤其适用于带哈希指纹的静态资源（如app.8f3a2d.js） - 基于压缩后内容生成 ETag，让客户端发条件请求时返回 304，复用本地已解压副本
- 确认反向代理（如 Nginx）未重复压缩或覆盖
Vary: Accept-Encoding头
验证是否生效，避开常见陷阱
上线后必须实测，不能只看代码有没有调 gzip.compress()：
- 浏览器 DevTools → Network → 查响应头是否有
Content-Encoding: gzip，对比 Size 与 Transfer Size 是否明显缩小 - 检查 CDN 或负载均衡器是否剥离了
Accept-Encoding请求头（某些老旧设备会删掉） - 确认没有对已压缩资源（如构建时生成的
.js.gz）再做一次运行时压缩
