直接看响应头和加载时间即可判断静态资源是否真正加速：cache-control、expires、last-modified/etag、x-cache-status等字段及两次请求的size与time变化是核心验证依据。
直接看响应头和加载时间，就能判断静态资源是否真正加速了。重点不是配了多少参数，而是浏览器实际拿到文件用了多久、有没有走缓存、服务器是不是真省力了。
查 HTTP 响应头里的缓存控制字段
这是最快速、最可靠的验证方式。用 curl -I 或浏览器开发者工具的 Network 面板查看关键响应头：
-
Cache-Control：确认是否包含
public, max-age=31536000（1年）或类似长效值；如果是no-cache或max-age=0，说明没生效 -
Expires：应为未来某个具体时间点（如
Wed, 01 Oct 2027 00:00:00 GMT），不是过去时间 -
Last-Modified / ETag：存在说明支持协商缓存；第二次请求若返回
304 Not Modified，就代表缓存命中 -
X-Cache-Status（如启用了 proxy_cache）：值为
HIT表示从 Nginx 缓存直接返回，MIS或空值说明仍回源
比对两次请求的实际耗时与传输量
在浏览器 Network 面板中，刷新页面后观察同一静态资源（如 main.css 或 logo.png）的两次表现：
- 首次加载：看 Size 列是“245 KB”，Time 是“182 ms”，说明完整下载
- 刷新后：若 Size 变成 “from disk cache” 或 “from memory cache”，Time 降到 “1–5 ms”，即缓存已生效
- 注意排除干扰：禁用开发者工具的 “Disable cache” 选项；清空浏览器缓存后再测；避免使用隐身模式自动禁用磁盘缓存
检查 Nginx 日志中的关键指标
在 access.log 中添加自定义日志字段，能直观反映加速效果：
- 在
log_format中加入：$upstream_cache_status $request_time $upstream_response_time - 正常加速后，日志里大量出现
HIT 0.002 0.001—— 表示缓存命中，总耗时仅 2ms，且几乎不依赖后端 - 若持续看到
MIS 0.215 0.213，说明每次都在回源，缓存配置可能路径不匹配、条件未满足，或资源本身带动态参数（如style.css?v=1.2但未处理 query string）
用工具验证缓存命中率与资源分发效率
单次请求只能看个体，批量压测才能看清系统级效果：
- 用
ab -n 1000 -c 100 http://yoursite.com/static/logo.png测试并发下平均响应时间，优化后应稳定在 - 配合
goaccess分析日志，筛选出.js .css .jpg等扩展名，看其Cache-Control字段分布和200/304状态码比例 - 若 304 占比超 60%，或 HIT 率 >85%，基本可确认静态资源层已高效运转
