验证cache-control是否生效需分层测试：先禁用缓存查响应头，再启用缓存看200(from memory/disk cache)或304状态码，辅以curl -i确认原始响应头，并检查服务器配置是否正确加载。
直接在浏览器里刷新页面，往往看不出 cache-control 是否真正生效——因为缓存行为可能被其他因素干扰（比如历史访问、扩展插件、预加载机制）。要准确验证，得绕过干扰、分层观察。
用开发者工具 Network 面板看真实响应头
这是最直观的第一步。打开 Chrome 或 Edge 的开发者工具（F12），切换到 Network 标签页，然后：
- 勾选 “Disable cache”（禁用缓存），强制每次请求都走网络，确保看到的是服务器真实返回的响应头
- 刷新页面或单独请求目标资源（如 /style.css 或 /api/data.json）
- 点击该请求 → 查看 Headers → Response Headers 区域，确认是否存在 Cache-Control 字段，值是否符合预期（例如 max-age=3600、no-cache 或 no-store）
对比两次请求的状态码和时间戳
禁用缓存只是“看得到”，要确认“是否真被缓存”，需做两次不带干扰的请求：
- 第一次请求后，取消勾选 “Disable cache”，再刷新同一资源
- 观察 Network 中该请求的状态码：如果是 200 (from memory cache) 或 200 (from disk cache)，说明强缓存生效
- 如果状态码是 304 Not Modified，说明强缓存已过期，但协商缓存（如 Last-Modified 或 ETag）起作用了
- 注意看 Timing 标签页里的 “Stalled” 和 “Waiting (TTFB)” 时间：强缓存命中时，TTFB 几乎为 0，且无网络传输
用 curl 模拟原始请求，排除浏览器干扰
浏览器有太多隐藏逻辑（如预连接、Service Worker、HTTPS 重定向等），curl 更干净：
- 运行 curl -I http://your-domain.com/resource.js，查看输出中是否有 Cache-Control 及其值
- 加 -H "Cache-Control: no-cache" 或 -H "If-None-Match: xxx" 可手动触发协商流程，验证 304 行为
- 配合 --include --head 确保只取响应头，避免下载内容影响判断
检查 Apache 配置是否实际生效
有时候响应头没出现，不是策略写错了，而是配置没加载或位置不对：
- 确认 mod_headers 已启用：a2enmod headers && systemctl reload apache2
- Header set 或 Header always set 指令必须放在重定向规则（如 RewriteRule）之后，否则可能被覆盖
- 若使用 .htaccess，确保 AllowOverride All 或至少包含 FileInfo 权限
- 修改后务必重启或重载 Apache：systemctl reload apache2（不要只改配置不生效）
