核心是控制变量、真实复现用户路径并交叉验证：用隐身模式+禁用缓存抓首屏耗时，对比刷新前后HTML及资源加载变化；结合X-Cache-Status、wrk压测、Nginx与后端日志统计命中率及后端调用量削减，精准量化缓存收益。
直接对比不同缓存策略下的页面加载耗时，核心是控制变量、真实复现用户访问路径，并排除干扰因素。不能只看单次刷新，而要结合客户端观测、服务端日志与系统指标交叉验证。
用浏览器开发者工具抓取真实首屏耗时
这是最贴近用户视角的方式，重点看“Network”标签页中关键资源的加载时间：
- 打开 Chrome 或 Edge，进入隐身模式（避免扩展或旧缓存干扰）
- F12 → Network → 勾选 “Disable cache” 取消勾选（确保测试真实缓存行为）
- 访问目标页面（如 /product/123），记录完整加载时间、HTML响应时间、关键 JS/CSS 加载耗时
- 刷新页面，对比第二次加载中 HTML 是否变为 from disk cache 或 from memory cache，以及对应耗时是否显著下降（例如从 600ms → 8ms）
- 配合 X-Cache-Status 响应头（如 HIT / MISS）确认该次 HTML 是否命中 Nginx 代理缓存
用命令行工具批量压测接口响应时间
针对 API 或动态页面路径（如 /api/recommend），用 wrk 或 ab 模拟并发请求，观察平均延迟和分布变化：
- 先在一种缓存策略下运行：wrk -t4 -c100 -d30s http://your.site/api/recommend
- 记录输出中的 Latency Distribution（尤其 90%、95% 分位值）和 Requests/sec
- 切换另一套缓存配置（如调整 proxy_cache_valid 或启用 proxy_cache_lock），reload Nginx 后重跑相同命令
- 对比两组结果：若新策略下 95% 延迟从 420ms 降至 35ms，且后端 access.log 中该接口调用量减少 90%，说明缓存生效并明显提速
结合后端日志与缓存命中率反推实际收益
页面加载耗时不仅取决于 Nginx 缓存，还受后端响应、网络传输、浏览器解析等影响。需剥离出“缓存节省的后端耗时”：
- 在后端服务（如 Node.js 或 PHP-FPM）日志中，为被缓存的接口添加唯一 trace ID，统计单位时间内请求数量
- 同时在 Nginx access.log 中加入 $upstream_cache_status 字段，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_cache_status"'
- 用脚本统计某时段内 HIT 占比（如 92%），再对比该时段后端日志中对应接口调用次数 —— 若后端调用仅占总请求数的 8%，说明缓存承担了 92% 的流量，这部分请求的后端处理耗时已被完全消除
- 这个“消除的后端耗时”就是页面加载中被缓存策略直接优化的部分
监控静态资源加载链路与缓存有效性
静态资源（JS/CSS/图片）通常走浏览器缓存，但其配置是否合理直接影响首屏速度：
- 检查 Nginx 配置中是否对 .js/.css/.png 等后缀设置了 expires 和 Cache-Control
- 在浏览器 Network 中查看某 JS 文件的 Response Headers，确认存在类似：Cache-Control: public, immutable, max-age=31536000
- 首次访问后，强制刷新（Ctrl+F5）仍应看到该文件状态为 memory cache 或 disk cache，耗时显示 0 ms
- 若修改文件内容但未改名，却仍返回旧版本，说明缓存策略过强；若每次都是 200（非 304），说明缓存未生效或被绕过
