304响应占比是衡量协商缓存是否生效的最直接指标，需结合请求路径、User-Agent、响应头字段、时间窗口等联动分析异常波动，并定位ETag/Last-Modified生成缺陷与Nginx协同策略问题，最后通过抓包、边界测试和基线告警闭环验证。
304 响应占比是衡量协商缓存是否生效的最直接指标。它本身不体现“好坏”，但异常波动（如从 30% 骤降至 1%）往往暴露服务端缓存逻辑、ETag/Last-Modified 生成机制或客户端行为链路中的关键问题。优化不是追求 100% 304，而是让该比例稳定反映真实数据复用率，并在变动与复用之间取得合理平衡。
从日志中识别 304 异常波动的真实信号
Nginx access log 中可通过 $status 字段统计 304 数量，再结合总请求数计算占比。但仅看比例不够，需联动分析以下字段：
-
关注请求路径一致性：确认统计的是目标 API（如
/api/home/list），排除静态资源或错误路径干扰； -
检查 User-Agent 分布：若 304 比例暴跌仅发生在某类客户端（如新版 App），说明其请求头可能未携带
If-None-Match或If-Modified-Since； -
比对响应头字段：用 log_format 添加
$sent_http_etag和$sent_http_last_modified，验证 200 响应是否稳定输出 ETag/Last-Modified；若大量 200 响应缺失这些头，协商缓存根本无法启动； - 排查时间窗口特征：是否集中在某次发布后？是否与运营配置变更、CDN 缓存穿透、或服务端本地 cache key 混用（如共享了用户无关的缓存实例）强相关？
定位服务端 ETag / Last-Modified 生成逻辑缺陷
304 失效的常见根源不在 Nginx 配置，而在上游应用生成的响应头不可靠：
- ETag 不稳定：若 ETag 基于动态内容（如插入当前时间戳、用户 session ID、随机数），每次响应都不同，浏览器永远无法命中 304；
- Last-Modified 精度不足：文件系统级修改时间只能精确到秒，若同一秒内多次更新资源，或资源内容未变但元数据被刷新，会导致误判；
- 动态数据混入静态标识：如主页 list 接口含用户进度（动态）+ 关卡配置（静态），却用全量数据哈希生成 ETag，只要任一用户进度变化，所有用户都会失效——这正是知识库中“重量级 list api 304 比例暴跌”的根本原因；
- 建议做法：对混合型接口，将静态部分与动态部分分离计算；例如 ETag = base64(sha256(静态配置版本 + 运营配置 hash))，动态字段不参与哈希。
调整 Nginx 层协商缓存协同策略
Nginx 本身不生成 ETag 或 Last-Modified，但可强化校验逻辑与缓存分发一致性：
-
避免代理层覆盖原始头：确认 upstream 服务返回的
ETag和Last-Modified未被 Nginx 或 CDN 错误清除或重写；禁用etag off;等覆盖指令； -
启用
if_modified_since精确模式：在 location 块中设置if_modified_since exact;，使 Nginx 严格比对秒级时间（而非默认的“大于等于”逻辑），减少因时钟偏差导致的误判； -
配合 Cache-Control 控制协商触发时机：对适合协商缓存的接口，返回
Cache-Control: public, max-age=0, must-revalidate，确保浏览器每次都会发起条件请求，而不是跳过协商直接回源； -
慎用
add_header覆盖 ETag：除非有强理由（如统一降级为弱 ETag），否则不要在 Nginx 中用add_header ETag ...替换上游值，易造成前后端标识不一致。
验证与持续监控的关键动作
优化后必须闭环验证，而非仅依赖日志比例回升：
-
抓包比对典型请求流：用 curl 或浏览器开发者工具，检查第二次请求是否携带
If-None-Match，服务端是否返回 304 且响应头不含响应体； - 构造边界用例测试：模拟静态数据未变但用户态更新，验证 ETag 是否不变；模拟运营配置更新，验证 ETag 是否变更并触发 200；
- 建立 304 占比基线告警：对核心接口设置浮动阈值（如 ±8%），当连续 5 分钟低于均值下限即触发告警，早于业务侧感知性能下降；
- 关联后端缓存命中率：若服务端自身有本地缓存（如 Redis），同步监控其命中率；304 比例骤降 + 后端缓存命中率同步下跌，大概率指向缓存 key 设计缺陷。
