Apache本身不支持缓存预热，mod_cache和mod_cache_disk仅为被动缓存机制，需通过外部脚本模拟请求、配合mod_proxy与正确响应头（如Cache-Control: public）触发缓存生成，并依赖版本化文件名实现一致性更新。
Apache 本身不支持缓存“预热”，mod_cache 和 mod_cache_disk 都是被动缓存机制——只有真实请求到达后才缓存响应。所谓“预热”，必须靠外部主动触发请求，再配合 proxy、cache、headers 等模块协同完成。关键不在 Apache 能不能“自动预热”，而在于如何让这些请求真正落盘、可命中、不被跳过。
预热的前提：确保静态资源能被 mod_cache_disk 缓存
很多配置看似启用缓存，实际全是 X-Cache: MISS，根本原因在于 Apache 对缓存条件极其严格：
- 必须启用
mod_proxy+mod_proxy_http，因为 mod_cache_disk 只对代理转发后的响应生效，不缓存 Apache 直接服务的文件（如 DocumentRoot 下的静态资源）； - Java 后端或反向代理目标必须返回带
Cache-Control: public, max-age=3600的响应头，仅max-age不够，缺public就被拒绝缓存； - 默认会忽略含
Set-Cookie的响应，需显式加CacheIgnoreHeaders Set-Cookie； -
CacheRoot目录（如/var/cache/apache2/mod_cache_disk）必须由 Apache 进程用户（如www-data）可写，否则日志报(13)Permission denied。
用脚本模拟请求实现“预热”
预热本质就是提前发一批 GET 请求，让热门 URL（如 /static/app.js、/api/products）走一遍代理链路，触发缓存生成。推荐用轻量脚本定期执行：
- 用
curl -I检查响应头是否含X-Cache: MISS或HIT，确认缓存链路通； - 写一个 Bash 或 Python 脚本，循环请求关键路径，例如：
curl -s -o /dev/null https://yoursite.com/static/main.abc123.js； - 结合
cron每日凌晨运行一次，或在 CI/CD 发布后立即触发； - 避免高频请求压垮后端，建议加
sleep 0.1间隔，并限制并发数。
一致性更新：靠版本化文件名 + 缓存失效组合
静态资源更新后，旧缓存若未及时清理，用户就会看到陈旧内容。Apache 不提供主动刷新接口，所以要绕开“更新缓存”这个思路，转为“让旧缓存自然失效+新请求命中新资源”：
- 构建阶段生成带内容哈希的文件名（如
main.f8a2e4.js），HTML 中直接引用该名字； - 部署时只替换新文件，旧文件保留在磁盘上——这样旧缓存仍可服务，但新 HTML 已指向新文件；
- Apache 不需要重写规则，也不需要手动清除缓存目录，只要
CacheEnable disk /static/配置正确，新请求自然命中新文件并缓存； - 若必须强制清空某类资源（如运营活动结束），可临时停用缓存配置、清空
CacheRoot目录，再重启 Apache，但这是兜底手段，非常规操作。
辅助配置增强可靠性
光有预热和版本化还不够，几个关键配置能大幅降低出错概率：
- 关闭
MultiViews：防止 Apache 尝试匹配app.js.gz或app.js.br导致 404； - 启用
mod_deflate和mod_mime：确保压缩文件（.gz/.br）能被识别并正确返回； - 用
mod_headers补全缺失头：比如后端没设Cache-Control，可在 Apache 中统一注入：Header set Cache-Control "public, max-age=2592000" "expr=%{REQUEST_URI} =~ m#^/static/#"； - 监控
X-Cache响应头和cache-status（需启用mod_cache_socache），验证命中率是否符合预期。
