定位缓存毛刺需区分慢在本地缓存I/O、回源链路或响应组装，关键是对齐$request_time、$upstream_response_time、$upstream_cache_status和$body_bytes_sent四字段归因分析。
要定位生产环境中偶发的缓存读取性能毛刺，核心不是只看“慢”，而是区分“慢在哪一环”：是 Nginx 本地缓存未命中导致回源？还是缓存命中了但读取或响应组装变慢？关键在于把 $request_time 和缓存状态、上游耗时、本地处理开销三者对齐记录。
必须记录的四个基础字段
仅加 $request_time 不够，需搭配以下变量才能做归因分析：
- $request_time：整个请求生命周期耗时（秒，毫秒精度），从收到首字节到发完响应。它是毛刺是否发生的总标尺
- $upstream_response_time：仅当触发回源时才有值，反映从建连到收完响应体的时间；若为“-”，说明未回源，纯本地缓存服务
- $upstream_cache_status：明确标识 HIT / MISS / EXPIRED / STALE 等状态，是判断是否走缓存路径的唯一依据
- $body_bytes_sent：结合静态资源类型（如 .js/.css/.woff2）和状态，可排除因空响应或小响应导致的计时失真
识别“伪缓存毛刺”的典型日志模式
很多看似缓存慢的问题，实际是误判。用字段组合快速过滤真实缓存层问题：
- 缓存命中但 request_time 异常高：$upstream_cache_status = HIT 且 $upstream_response_time = "-"，但 $request_time > 0.1 → 毛刺发生在 Nginx 本地：可能是磁盘缓存 I/O 延迟（尤其使用 proxy_cache_path 的 path 参数未配 fastcgi_cache_path 或 inactive 超短）、或 gzip 压缩阻塞（检查 gzip_vary/gzip_types 配置）
- 缓存失效引发的连锁毛刺：$upstream_cache_status = EXPIRED 或 MISS，且 $upstream_response_time 接近 $request_time → 回源链路本身正常，但大量 EXPIRED 同时发生（比如源站修改了 Cache-Control，或 Nginx reload 后缓存清空），造成瞬时回源洪峰
- STALE 状态下 request_time 偏高：$upstream_cache_status = STALE，但 $request_time 显著高于平时 HIT 值 → 说明 Nginx 正在后台异步更新缓存（proxy_cache_use_stale updating），而前台仍返回旧内容；此时高耗时往往来自锁竞争或后台 fetch 占用 worker 连接
补充两个强定位字段提升归因效率
光靠时间差还不够，需绑定上下文才能锁定具体请求和资源：
- $request_uri + $host：避免因泛域名或路径正则匹配模糊导致的统计偏差；建议对静态资源路径做 map 提取简写名（如 /static/v2/app.js → static_js）
- $http_x_request_id 或 $request_id：当发现某次 $request_time 突增，可用该 ID 关联 access_log 与 error_log（例如查是否有 “cache lock failed” 或 “upstream timed out”），确认是否遭遇缓存锁争用或 upstream 超时重试
一个面向缓存毛刺诊断的日志格式示例
放在 http 块中定义，专用于 cache 相关 location：
log_format cache_debug '$time_iso8601|$request_id|$host|$request_uri|' '$status|$upstream_cache_status|' '$request_time|$upstream_response_time|' '$body_bytes_sent|$http_user_agent';
然后在静态资源 location 中启用：
location ~* \.(js|css|png|jpg|woff2?)$ {
proxy_cache my_cache;
access_log /var/log/nginx/cache_debug.log cache_debug;
}
