mod_deflate不支持按mime类型设置不同压缩级别，需通过setenvifnocase配合force-gzip环境变量和deflatecompressionlevel（≥2.4.10）间接实现；推荐deflatecompressionlevel 6为起点，避免对json、图片等无效压缩。
mod_deflate 本身不支持 per-MIME-type 压缩级别
Apache 的 DeflateCompressionLevel 是全局配置项，只能设一个值（1–9），无法为 application/json 设 9、为 text/css 设 6。所谓“按类型设不同压缩比”，实际是靠环境变量 + 条件过滤间接实现的。
用 SetEnvIfNoCase + force-gzip 实现“逻辑分级”
通过匹配 Content-Type 值设置环境变量，再配合 DeflateCompressionLevel 的局部覆盖能力（需 Apache ≥2.4.10），可达成事实上的分类型强度控制：
-
SetEnvIfNoCase Content-Type "application/(?:json|javascript)" force-gzip→ 触发高压缩 -
SetEnvIfNoCase Content-Type "text/(?:html|css)" force-gzip→ 触发中等压缩 -
SetEnvIfNoCase Content-Type "image/|video/|application/pdf" no-gzip→ 显式禁用
注意：force-gzip 只是 Apache 内部识别的标记名，不是标准头；它必须和 DeflateCompressionLevel 配合使用，且只在 <ifmodule mod_deflate.c></ifmodule> 块内生效。
DeflateCompressionLevel 6 是多数场景的合理起点
压缩比从 6 升到 9，通常只多压 1–3%，但 CPU 时间可能翻倍。尤其对高频 JSON API，高并发下容易拖慢响应。实测中：
-
application/json小于 1KB：压缩收益极低，no-gzip更稳 -
text/html含大量空格/换行：DeflateCompressionLevel 6已足够 - 若真需 JSON 强压，应先确认后端未提前写响应体（如 Java 中调用
response.getOutputStream().write()会绕过 mod_deflate）
别信 AddOutputFilterByType DEFLATE image/* 这类配置
很多文档示例里写了 AddOutputFilterByType DEFLATE image/jpeg，这不仅无效，还浪费 CPU。JPEG/PNG/MP4 等本身已是高压缩格式，zlib 再 deflate 几乎不减体积，反而增加延迟。验证方法很简单：
开启 DeflateFilterNote 日志后，你会看到大量 INFLATE: 0 记录——说明输入流长度为 0 或压缩后无收益，被跳过了。这不是 bug，是模块在做正确的事。
