Apache mod_deflate不区分静态或动态内容，只压缩满足条件的HTTP响应体；关键在于动态内容需返回可压缩MIME类型（如application/json）、由Apache代理接收、未提前提交且未设Content-Encoding头，配置应使用AddOutputFilterByType而非扩展名匹配，并通过Content-Encoding:gzip和Vary头验证生效。
确认 Apache 正在处理动态响应
mod_deflate 只对 Apache 自己生成或代理接收后再发出的响应生效。如果你用的是：
-
Tomcat / Spring Boot 独立运行：mod_deflate 不起作用，需改配 Tomcat 的
Connector中compression="on" - Apache + mod_proxy_http 或 mod_proxy_ajp 前置 Java 应用：这是适用场景，Apache 在收到后端返回的响应后，再决定是否压缩
只对文本类动态内容启用压缩
HTML、JSON、XML、JS、CSS 这些由后端动态生成的文本内容，天然适合压缩。配置必须基于 MIME 类型，而非文件扩展名：
Apache 2.4.62
下载
Apache 2.4.62 官方 tar.gz 源码包是 Linux 及类 Unix 系统构建 Web 服务器的核心基础。通过源码编译安装，开发者能够灵活定制模块、优化性能并精准控制安装路径，满足多样化的业务需求。
- 在
<IfModule mod_deflate.c>块中写：AddOutputFilterByType DEFLATE text/html application/json application/xml text/javascript application/javascript text/css - 避免用
AddOutputFilter DEFLATE php js html—— 这依赖AddType映射，而动态响应往往不走扩展名匹配逻辑，极易失效 - 确保 Java 应用返回的响应头包含正确的
Content-Type，例如application/json;charset=UTF-8，否则 Apache 不会匹配到
避开常见干扰点
动态内容压缩失败，多数不是因为没配，而是被隐性规则绕过：
- 后端主动设置
Content-Encoding: gzip→ Apache 认为已压缩，直接跳过。务必让 Java 应用不设该头 - Servlet 提前调用
response.getOutputStream().flush()或写入少量内容后 commit → 响应流已部分发送，Apache 无法完整捕获并压缩。应确保输出完成后再交由 Apache 处理 - 响应体太小（默认低于 256 字节）→ mod_deflate 自动跳过，属正常行为；若关键 inline script 被忽略，可加
SetEnvIfNoCase Content-Length "^[0-9]{1,3}$" no-gzip调整阈值（慎用） - 图片、PDF、ZIP 等二进制资源本就不该压缩，用
SetEnvIfNoCase Request_URI \.(?:png|jpg|pdf|zip)$ no-gzip明确排除
验证是否真实生效
不要看文件大小，要看网络传输结果：
- 用浏览器开发者工具打开 Network 标签页，选中一个 HTML 或 JSON 请求
- 检查响应头：必须有
Content-Encoding: gzip（或deflate） - 同时应有
Vary: Accept-Encoding，表明缓存层（如 CDN）会按编码方式区分缓存 - 可辅以命令行验证：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/api/data，观察是否返回Content-Encoding: gzip
