Django自带GZipMiddleware已足够应对绝大多数生产场景，它压缩HTTP响应体，而django-compressor用于静态资源优化，二者功能完全不同。
Django 自带的 GZipMiddleware 已足够应对绝大多数生产场景，不需要额外引入 django-compression（即 django-compressor）来实现 Gzip 响应压缩。两者解决的是完全不同的问题：前者压缩 HTTP 响应体（传输层），后者压缩静态资源（如 CSS/JS 文件内容并合并、预编译）。
如果你看到“Django-Compression 加载 Gzip”的说法，大概率是混淆了概念，或误用了第三方库名（比如把 django-compressor 当成压缩响应的工具）。下面直接说清楚怎么做、为什么、容易踩什么坑。
用错库：django-compressor ≠ Gzip 响应压缩
django-compressor 的核心职责是：在模板渲染阶段，把多个 <link> / <script> 合并、压缩（如移除空格、注释）、生成哈希文件名，并写入静态文件系统。它不干预 HTTP 响应头、不处理 Accept-Encoding、不调用 gzip.compress()。
常见误操作包括：
立即学习“Python免费学习笔记（深入）”；
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 在
settings.py里配了COMPRESS_ENABLED = True就以为响应自动 gzip 了 - 发现 API JSON 没被压缩，转头去给
compressor配GZIP_CONTENT_TYPES—— 这个配置根本不存在于该库中 - 用
compressor处理动态视图返回的 JSON 字符串，结果报TemplateSyntaxError
真正该用的：GZipMiddleware + 关键配置项
Django 官方中间件 GZipMiddleware 是唯一推荐的响应级 Gzip 方案。它默认启用基础逻辑，但生产环境必须显式调整几个参数：
-
GZIP_MIN_LENGTH = 1024：默认是 200 字节，太低会导致大量小响应（如{"ok":true}）反复压缩反而拖慢 CPU；设为 1KB 更合理 -
GZIP_CONTENT_TYPES必须显式声明：默认只压text/*类型，但现代 API 返回的application/json不在其中，不加这行，JSON 永远不会被压缩 - 中间件顺序不能错：
GZipMiddleware要放在CommonMiddleware之后、SecurityMiddleware之前（确保Vary: Accept-Encoding被正确设置）
示例配置：
GZIP_MIN_LENGTH = 1024
GZIP_CONTENT_TYPES = [
"text/css",
"text/javascript",
"text/html",
"application/javascript",
"application/json",
"application/xml",
]
MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware",
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.common.CommonMiddleware",
"django.middleware.gzip.GZipMiddleware", # ← 放这里
# ... 其他中间件
]
curl 和浏览器验证时容易忽略的细节
光看响应头 Content-Encoding: gzip 不够，还要确认三件事：
- 请求必须带
Accept-Encoding: gzip，否则中间件直接跳过（curl -H "Accept-Encoding: gzip" -I https://yoursite.com/api/） - 响应不能已有
Content-Encoding头（比如你手动在视图里加了response["Content-Encoding"] = "gzip"，中间件会放弃处理） - 如果用了 Nginx/Apache 前置代理，它们可能已做了 Gzip —— 此时 Django 的中间件实际没生效，但用户仍看到压缩效果；要确认真实链路，得关掉反向代理的压缩再测
局部压缩用 gzip_page 装饰器时的边界情况
@gzip_page 是函数级开关，但它依赖同一个底层逻辑，所以同样受 GZIP_MIN_LENGTH 和 GZIP_CONTENT_TYPES 控制。特别注意：
- 它对类视图无效，必须配合
@method_decorator(gzip_page, name="dispatch")使用 - 如果视图返回的是流式响应（
StreamingHttpResponse），gzip_page会静默失效 —— 中间件能处理流式，装饰器不行 - 装饰器和中间件叠加不会重复压缩，因为中间件检测到已有
Content-Encoding头就退出
真正影响压缩效果的，从来不是“有没有开”，而是 GZIP_MIN_LENGTH 是否合理、GZIP_CONTENT_TYPES 是否覆盖你的实际 MIME 类型、以及前端是否真发了 Accept-Encoding。其他所有“高级压缩库”在响应压缩这件事上，基本都是画蛇添足。
