mod_deflate 未默认启用，需先运行命令确认模块加载，再配置压缩规则；仅对文本类资源如 text/html、text/css 等启用压缩，排除 image/、video/ 等已高压缩率类型。
mod_deflate 是否已启用？先确认再配置
Apache 默认不启用 mod_deflate，直接写配置会静默失效。必须先检查模块是否加载，否则所有压缩规则都不起作用。
- 运行
apachectl -M | grep deflate（Linux/macOS）或httpd -M | findstr deflate（Windows），看到deflate_module (shared)才算就位 - 若未出现，需在
httpd.conf或apache2.conf中取消注释：LoadModule deflate_module modules/mod_deflate.so - Windows 下路径可能含空格，确保
modules/目录存在且权限可读；Linux 若用包管理器安装（如 apt/yum），模块通常在/usr/lib/apache2/modules/或/usr/lib64/httpd/modules/，路径错会导致启动失败
压缩哪些响应才合理？别盲目全开
mod_deflate 对已压缩资源（如 JPEG、PNG、MP4）再压不仅无效，还会白耗 CPU。重点应放在文本类资源上，且要避开某些低收益或高风险类型。
- 推荐只压缩：
text/html、text/css、text/javascript、application/json、application/javascript - 明确排除：
image/*、video/*、audio/*、application/pdf—— 这些本身有高压缩率，再压反而拖慢响应 - 注意
application/json在旧版 Apache（AddType application/json .json - 避免对小文件压缩（如 DeflateFilterNote 并开启日志，会发现大量
INFLATE: 0记录，说明压缩被跳过——这是正常行为，不是配置失败
关键参数怎么设？DeflateCompressionLevel 和 SetOutputFilter 的取舍
压缩级别不是越高越好，而是在带宽节省和 CPU 开销间找平衡；过滤器启用方式也影响作用范围。
-
DeflateCompressionLevel推荐设为6（默认值），9比6多压约 1–3%，但 CPU 时间翻倍，对高并发站点明显拖累 - 用
AddOutputFilterByType DEFLATE ...更安全：它只对匹配 MIME 类型的响应生效，不依赖文件扩展名，适合 REST API 返回 JSON 的场景 - 避免用
SetOutputFilter DEFLATE全局启用——它会对所有响应尝试压缩，包括二进制响应头错误的资源，容易引发客户端解析失败 - 如果用了反向代理（如 Nginx 前置），确保
Accept-Encoding请求头透传，否则 Apache 根本收不到gzip声明，压缩不会触发
如何验证压缩生效？别只看响应头
看到 Content-Encoding: gzip 不代表真压缩成功，得核对实际字节变化。常见假阳性是缓存、CDN 或前端代理覆盖了压缩结果。
- 用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/style.css查响应头，确认含Content-Encoding: gzip和Vary: Accept-Encoding - 再执行完整请求：
curl -H "Accept-Encoding: gzip" -s -w "%{size_download}\n" -o /dev/null https://yoursite.com/script.js，对比不带头时的大小，差值应 >20% - 浏览器开发者工具 Network 面板里，点开资源 → Headers → Response Headers，检查
Content-Encoding；但注意：若资源被 Service Worker 缓存，可能返回的是未压缩副本 - 最可靠方式：在服务器本地用
curl直连 Apache（绕过 CDN/Nginx），并加--compressed参数，观察解压后内容是否完整——乱码或截断说明压缩/解压链某环出错
Accept-Encoding 或覆写响应头。这几个点串不起来，光调参数没用。
