Apache默认不按MIME类型自动压缩，需用AddOutputFilter+SetEnvIf组合替代已弃用的AddOutputFilterByType；DEFLATE过滤器用zlib deflate算法，非gzip格式但兼容；通过SetEnvIf可实现分类型、分强度、分UA的压缩控制。
Apache 默认不按 MIME 类型设置 Gzip 压缩优先级，必须手动用 AddOutputFilterByType 或现代等效方式显式声明，否则 text/html 和 application/javascript 等类型可能被漏压或误压。
为什么 AddOutputFilterByType 已被弃用但仍在用
Apache 2.4+ 官方推荐改用 AddOutputFilter + SetEnvIf 组合，因为 AddOutputFilterByType 依赖响应头中的 Content-Type，而该字段可能被后端（如 PHP、Node.js）覆盖或缺失，导致压缩失效。但很多线上配置仍沿用旧写法，只因它写起来快、逻辑直觉强。
- 旧写法（兼容但风险高）：
AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json
- 新写法（推荐）：
SetEnvIfNoCase Content-Type "(?:text|application)/(?:html|css|javascript|json|xml|x-javascript)" no-gzip=0<br>AddOutputFilter DEFLATE .html .css .js .json .xml
- 关键区别：新写法先用正则匹配
Content-Type值设环境变量，再按文件扩展名触发过滤——双重保险，避免后端未设头时漏压
DEFLATE 和 GZIP 过滤器的实际差异
Apache 的 mod_deflate 模块只提供 DEFLATE 过滤器，它默认使用 zlib 的 deflate 算法（RFC 1951），不是 gzip 格式（RFC 1952）。但浏览器接受 Content-Encoding: deflate，也接受 gzip；关键是服务端不能伪造响应头。
- 不要手动设置
Content-Encoding: gzip——DEFLATE过滤器会自动加正确头 - 若强制用
gzip算法（比如兼容极老客户端），需启用mod_gzip（已废弃）或用mod_deflate配合DeflateCompressionLevel和DeflateFilterNote日志验证实际算法 - 真实影响：某些 CDN（如 Cloudflare）对
deflate编码支持不一致，建议统一用gzip响应头 → 实际只需确保AddOutputFilter DEFLATE正常工作，Apache 会协商出最优编码
如何为不同 MIME 类型设定压缩“优先级”和强度
Apache 本身没有“压缩优先级”概念，但可通过 SetEnvIf 分层控制是否启用、用多大压缩比、是否跳过特定 UA —— 这就是事实上的优先级。
- 高优先级（必压、高压缩）：
SetEnvIfNoCase Content-Type "application/(?:json|javascript|wasm)" force-gzip<br>DeflateCompressionLevel 9
- 中优先级（常规压、平衡速度与体积）：
SetEnvIfNoCase Content-Type "text/(?:html|css)" force-gzip<br>DeflateCompressionLevel 6
- 低优先级/禁用（避免损坏二进制）：
SetEnvIfNoCase Request_URI "\.(?:jpg|jpeg|png|gif|webp|woff2)$" no-gzip<br>SetEnvIfNoCase User-Agent "MSIE [4-6]" no-gzip
- 注意：
force-gzip是自定义 env 名，需配合AddOutputFilter DEFLATE使用；no-gzip是 mod_deflate 内置识别名，设了就跳过
真正容易被忽略的是：压缩行为受 Content-Length 响应头影响——如果后端流式输出且没设该头，mod_deflate 可能无法压缩或触发 chunked 编码异常。上线前务必用 curl -I 检查真实响应头是否含 Content-Encoding: gzip 和 Vary: Accept-Encoding。
