gzip中间件默认不压缩application/json响应，需手动在compressible_types中添加；静态文件需预压缩或反向代理处理；必须设置Vary: Accept-Encoding防止缓存错误。
为什么 gzip 中间件没压上 JSON 响应？
默认情况下，多数 Python Web 框架的 gzip 中间件只压缩 text/html、text/css、application/javascript 这类 MIME 类型，而 application/json 通常被排除在外——哪怕你明确设置了 Content-Encoding: gzip 请求头，响应体依然明文返回。
- 检查中间件配置中的
mime_types或compressible_types参数，确认是否包含"application/json" - Django 的
GZipMiddleware默认不处理 JSON；FastAPI 的GzipMiddleware默认也不含application/json；Starlette 同理 - 某些中间件（如
starlette.middleware.gzip.GZipMiddleware）允许传入compressible_types列表，直接补上即可：app.add_middleware(GZipMiddleware, compressible_types={"application/json", "text/html", "application/javascript"}) - 注意顺序：Gzip 中间件必须在路由/视图中间件之后、响应生成之前生效，否则 JSON 已经序列化成 bytes 就无法再压缩
gzip 压缩静态资源时路径没生效？
静态文件本身不经过中间件逻辑——GZipMiddleware 只作用于动态响应。想压缩 /static/js/app.js 这类文件，得靠预压缩或反向代理（如 Nginx），或者用构建工具生成 .js.gz 文件并配置服务器自动响应 Accept-Encoding: gzip。
- 不要指望
GZipMiddleware自动读取并压缩磁盘上的.css或.js文件；它只对内存中生成的响应体做流式压缩 - 若用
whitenoise（Django）或StaticFilesConfig（FastAPI），需额外启用其内置压缩支持，例如 whitenoise 的WHITENOISE_USE_FINDERS = True和WHITENOISE_AUTOREFRESH = True不起压缩作用，必须设WHITENOISE_COMPRESS = True - 更稳妥的做法：构建阶段用
gzip -k file.js生成file.js.gz，再让服务器（如 Nginx）配gzip_static on;，这样零运行时开销
压缩后响应头缺失 Vary: Accept-Encoding？
这个响应头不是可选的——它告诉缓存层（CDN、浏览器、代理）：同一个 URL 的响应可能因请求头不同而不同。没有它，gzip 压缩后的响应可能被错误地缓存并返回给不支持 gzip 的客户端，导致乱码或解析失败。
- 大多数成熟中间件（如 Starlette、Django 的 GZipMiddleware）会自动加
Vary: Accept-Encoding，但自定义中间件或老版本可能漏掉 - 手动加的方法很简单：在压缩完响应体后，执行
response.headers["Vary"] = "Accept-Encoding"（注意不要覆盖已有Vary值，需合并） - 如果用了多层缓存（比如 Cloudflare + Nginx + 应用），某一层删掉了
Vary，问题会变得隐蔽——建议用curl -I https://yoursite.com/api/data实测响应头
压缩小 JSON（
gzip 对极短文本压缩收益低，且压缩过程本身有 CPU 开销。实测表明，小于 ~500 字节的 JSON，压缩后体积可能不变甚至略增，而耗时增加 0.5–2ms（取决于 Python 环境和 zlib 设置）。
立即学习“Python免费学习笔记（深入）”；
- 中间件一般提供
minimum_size参数（如 Starlette 的minimum_size=1000），建议设为1000或1500，跳过微小响应 - 不要全局开启压缩后就不管了；配合日志或监控，观察实际压缩率（
len(compressed)/len(original)）和延迟分布 - 如果 API 大量返回
{"ok": true}这类响应，考虑用gzip.compress(b'{"ok":true}', level=1)测试真实开销，而不是依赖默认 level=6
