Apache不支持自动识别预压缩文件，需手动配置mod_rewrite、mod_headers和mod_deflate：先生成.css.gz等文件，再用重写规则匹配并切换路径，配合Header设置Content-Encoding和Content-Type，并禁用ETag确保缓存一致。

Apache 本身不支持像 Nginx 的 gzip_static on 那样自动识别并发送已存在的 .js.gz 或 .css.gz 文件。要实现“有预压缩文件就发 .gz，没有就走实时压缩”的自动化效果，必须手动组合 mod_rewrite、mod_headers 和 mod_deflate，并配合严格的文件准备规范。

前提：必须提前生成并部署 .gz 文件

Apache 不会帮你压缩，只负责路由和响应头设置。你需要在部署时或构建流程中批量生成：

• 对每个 style.css 运行 gzip -k -9 style.css，得到 style.css.gz
• 确保 .gz 文件与原文件权限一致（如 644），否则返回 403
• 更新源文件后必须重新生成对应 .gz 文件——Apache 不校验时效性或一致性

核心重写逻辑：按需匹配并切换路径

在 VirtualHost 或主配置中启用 mod_rewrite，添加如下规则：

<ifmodule mod_rewrite.c>
  RewriteEngine On
  # 只对支持 gzip 的客户端生效
  RewriteCond %{HTTP:Accept-Encoding} gzip
  # 检查同名 .gz 文件是否存在（注意：-f 对符号链接默认不生效，需确保 FollowSymLinks）
  RewriteCond %{REQUEST_FILENAME}.gz -f
  # 将 /a.js → /a.js.gz，/b.css → /b.css.gz
  RewriteRule ^(.+\.(js|css|html|xml|json|svg))$ $1.gz [L]
</ifmodule>

关键响应头设置：Content-Encoding + Content-Type

仅重写路径还不够，Apache 默认不会为 .gz 文件自动设 Content-Encoding: gzip，且会丢失原始 MIME 类型。需用 mod_headers 强制补全：

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

<ifmodule mod_headers.c>
  # 告诉缓存系统：响应内容随 Accept-Encoding 变化
  Header append Vary Accept-Encoding
<p><filesmatch>
Header set Content-Encoding gzip
Header set Content-Type "application/javascript; charset=utf-8"
</filesmatch></p>
<p><filesmatch>
Header set Content-Encoding gzip
Header set Content-Type "text/css; charset=utf-8"
</filesmatch></p>
<p><filesmatch>
Header set Content-Encoding gzip
Header set Content-Type "text/html; charset=utf-8"
</filesmatch></p></ifmodule>

注意：Content-Type 必须按原始类型硬编码；Apache 不会从 .js.gz 推断出它是 JS，也不会调用 mod_mime 二次识别。

禁用 ETag 保证缓存一致性

如果启用 FileETag（默认常开启），同一资源的 .js 和 .js.gz 可能产生不同 ETag，导致 CDN 或浏览器缓存混乱。建议全局关闭：

<ifmodule mod_headers.c>
  Header unset ETag
</ifmodule>
FileETag None

同时，在静态资源路径上禁用 ETag 是强推荐做法，避免预压缩与未压缩版本被当作不同资源处理。