必须启用loglevel cache:debug并检查error_log中“cache”“disk_cache”等关键词，确认mod_cache是否介入请求及未缓存原因；同时配置access_log含%{cache-status}e字段直观显示hit/miss，并验证cacheroot权限与存储模块初始化状态。
排查 mod_cache 运行异常，不能只看有没有缓存命中，关键要从日志里确认它“是否真正参与了请求处理”以及“为什么没缓存”。apache 默认日志不记录缓存行为，必须主动启用相关模块和日志级别。
开启 cache 模块的详细日志输出
mod_cache 本身不写独立日志，但可通过 ErrorLog 配合 LogLevel 调整来暴露其决策过程。在主配置或虚拟主机中设置：
- 启用 debug 级别： LogLevel info cache:debug（Apache ≥ 2.4.10）
- 确保 error_log 文件路径可写，且磁盘空间充足
- 重启 Apache 后，访问目标 URL，立即检查 error_log 中含 “cache”, “disk_cache”, “mem_cache” 的行
你会看到类似这样的关键信息：
- cache: debug] Adding CACHE filter for /api/list → 表示 mod_cache 已介入该请求
- cache: debug] Not caching response: missing Cache-Control or Expires → 告诉你后端未返回可缓存响应头
- disk_cache: debug] Key for /api/list?category=book is ... → 显示实际生成的缓存键，可用于验证 query string 是否被正确标准化
- cache: debug] Serving cached content for /api/list → 确认命中成功
结合 access_log 观察缓存效果
仅靠 error_log 不够直观，需在 access_log 中加入缓存状态字段。修改 LogFormat：
- 添加 %D（请求处理总微秒）、%{cache-status}e（mod_cache 状态）等变量
- 推荐格式：LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{cache-status}e %D" combined-cache
- 在 VirtualHost 中使用：CustomLog logs/access_log combined-cache
日志样例：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 192.168.1.10 - - [10/Oct/2026:05:20:12] "GET /api/list?page=2 HTTP/1.1" 200 1245 "-" "curl/7.68.0" HIT 12489
- 192.168.1.10 - - [10/Oct/2026:05:20:13] "GET /api/list?page=3 HTTP/1.1" 200 1245 "-" "curl/7.68.0" MISS 87210
注意：HIT/MISS/REVALIDATE/BYPASS 这些值来自 mod_cache 内部状态，直接反映缓存行为；若始终是 BYPASS，说明请求根本没进缓存流程（可能被其他模块提前拦截或配置未生效）。
重点排查几类典型 error_log 线索
遇到缓存不工作时，优先搜索 error_log 中以下关键词：
- "not caching response: no cacheable headers" → 后端响应缺少 Cache-Control: public 或 Expires，或包含 Set-Cookie（默认不缓存）
- "cache: debug] Skipping cache for request with Vary: *" → Vary 头设为通配符，强制不缓存；检查是否误加了 Vary: *
- "disk_cache: error] Cannot create directory" → CacheRoot 权限错误或路径不存在，导致 disk_cache 初始化失败
- "cache: debug] Not caching response: response size too large" → 超过 MCacheMaxObjectSize（mem_cache）或 disk_cache 限制
- "cache: debug] Not caching response: status 5xx or 4xx" → 错误响应默认不缓存，需用 CacheIgnoreNoLastMod + CacheIgnoreCacheControl 配合显式允许
验证缓存存储层是否就绪
mod_cache 依赖 storage 模块（如 mod_disk_cache 或 mod_socache_dbm），它们的日志也藏在 error_log 里：
- 启动时搜 "disk_cache: initialized" 或 "socache_dbm: initialized"，确认模块加载成功
- 运行中搜 "disk_cache: error"，常见于 CacheRoot 目录 inode 耗尽、磁盘满、或文件系统不支持硬链接（影响原子写入）
- 用 htcacheclean -p /path/to/cacheroot -l 手动检查缓存目录结构是否生成，避免配置写了但缓存根目录压根没创建
