直接在 Nginx 日志中记录 $sent_http_cache_control 可审计全站缓存策略合规性，该变量真实反映最终发给客户端的 Cache-Control 值，配合日志分析可快速识别缺失、违规或未控缓存行为。
直接在 Nginx 日志中记录 $sent_http_cache_control，就能看到网关层实际响应给客户端的 Cache-Control 值，从而验证静态资源是否按预期下发了强缓存策略（如 public, max-age=31536000）。
确认变量可用且响应头已设置
$sent_http_cache_control 是 Nginx 内置变量，仅在响应头中真正写入了 Cache-Control 时才有值；若后端未设置、被覆盖或被清除（如用 proxy_hide_header 或 add_header 覆盖），该变量为空字符串。需确保：
- 静态资源路径匹配了配置强缓存的 location 块（如
location ~* \.(js|css|png|jpg|woff2)$） - 使用
add_header Cache-Control "public, max-age=31536000" always;（always确保对 2xx/3xx 响应都生效） - 未启用
proxy_hide_header Cache-Control或类似拦截逻辑
在 access_log 中输出该变量
修改 log_format，加入该变量，例如：
log_format cache_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$sent_http_cache_control";再在 server 或 location 中启用：
重启 Nginx 后，日志每行末尾就会出现实际下发的 Cache-Control 值，比如："public, max-age=31536000" 或 "no-cache" 或空字段（表示未下发）。
用日志快速复核缓存策略执行效果
通过日志可直观识别异常情况：
- 预期强缓存但日志中为
no-cache或no-store→ 检查是否被上游服务覆盖、或命中了未配置缓存的 fallback 逻辑 - 大量请求日志中该字段为空 → 说明响应根本没带
Cache-Control，可能是 location 未匹配、或被add_header指令遗漏 - 同一资源不同请求出现不同值（如部分为
max-age=0）→ 可能存在条件判断逻辑（如带 query 参数时降级）、或被某些中间件动态改写
可配合 awk 或 grep 快速统计：
注意与 $upstream_http_cache_control 的区别
$sent_http_cache_control 是最终发给客户端的值；而 $upstream_http_cache_control 是上游响应头原始值。两者不一致时，说明 Nginx 层做了改写（如用 add_header 覆盖或 proxy_hide_header 清除）。对比二者可定位是上游问题还是网关配置问题。
