mod_cache缓存完整HTTP响应（含响应头），需满足Cache-Control/Expires头、可缓存状态码及GET/HEAD方法；Vary头影响缓存键，Set-Cookie默认禁用缓存，自定义头随响应一并缓存返回。
Apache 的 mod_cache 本身不直接“存储”HTTP响应头——它缓存的是完整的 HTTP 响应（包括状态行、响应头和响应体），响应头自然随响应一起被缓存和后续复用。关键在于：**能否正确缓存、是否在响应中保留原始头、以及如何控制哪些头参与缓存决策或被传递给客户端**。
确保 mod_cache 正确启用并识别可缓存响应
Apache 默认不会缓存所有响应，需满足明确的缓存策略条件：
-
响应必须有合法的 Cache-Control 或 Expires 头：例如
Cache-Control: public, max-age=3600或Expires: Wed, 01 Jan 2025 00:00:00 GMT；无此类头时，mod_cache通常跳过缓存（除非配置了CacheIgnoreNoLastModified On并配合其他指令）。 -
响应状态码需默认可缓存：如 200、203、300、301、302、410，默认支持；404、5xx 等通常不缓存，可通过
CacheIgnoreCacheControl或CacheStorePrivate等调整，但需谨慎。 - 请求方法需为 GET 或 HEAD：POST/PUT/DELETE 等默认不缓存，不可通过简单配置开启（涉及语义安全）。
控制响应头的缓存行为与透传
某些响应头（如 Set-Cookie、Vary、Authorization）会显著影响缓存逻辑或安全性：
-
Vary头决定缓存键的维度：例如Vary: User-Agent, Accept-Encoding表示需为不同 UA 和压缩方式分别缓存；Apache 自动识别并应用该头，无需额外配置。 -
Set-Cookie默认阻止缓存：因含用户私有信息；若确需缓存（如静态资源带无关 Cookie），可加CacheIgnoreHeaders Set-Cookie，但务必确认无敏感数据。 -
自定义头默认会被缓存和返回：如你的 Java 应用设置了
X-App-Version: 1.2.3，只要响应被缓存，该头就会随缓存副本一同返回给后续请求。
Java 应用侧需配合的关键点
Tomcat/Jetty 等容器作为后端，其输出直接影响 Apache 能否缓存：
立即学习“Java免费学习笔记（深入）”；
-
显式设置缓存头：在 Java Servlet 或 Spring Controller 中添加：
response.setHeader("Cache-Control", "public, max-age=3600");
或对静态资源启用 Spring Boot 的spring.web.resources.cache.cachecontrol.max-age=3600。 -
避免动态头污染缓存：不要为每个请求生成唯一
ETag或Last-Modified（除非真实变化），否则导致缓存失效；静态资源建议用固定值或文件哈希。 -
禁用不必要的响应头：如
Pragma: no-cache会覆盖Cache-Control，应移除；Spring Boot 可通过server.response.remove-heads=Pragma配置。
验证缓存是否生效及头是否完整
通过 curl 检查实际响应：
- 首次请求（回源）：
curl -I http://your-app/resource.js
查看是否有X-Cache-Miss（或类似自定义头）及原始响应头。 - 二次请求（命中）：
curl -I http://your-app/resource.js
应见X-Cache-Hit，且所有原始响应头（包括自定义头）均存在，Date和Age头体现缓存时间。 - 检查 Apache 日志（启用
CacheLock或CacheIgnoreHeaders相关日志级别）可进一步定位拦截原因。
