max-age 和 ETag 一起返回 浏览器还会发条件请求吗

静态资源同时带了 Cache-Control: max-age=86400 和 ETag，发布后一天内浏览器一次请求都不发，用户始终看旧文件，服务端 304 计数也是 0。日志里能对上时间点，这种反而好排。

新鲜期内浏览器直接用本地副本，根本不会去问服务端，ETag 没有机会参与。两个机制不是叠加，强缓存优先。要让它回源验证，就得把 max-age 设小或者用 no-cache。这一点先确认清楚，后面就不用反复试。

Cache-Control: no-cache
ETag: "v8f3a1"
# 或
Cache-Control: public, max-age=31536000, immutable

「强缓存与协商缓存」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。偶发问题先统计频率，一小时几次和一天一次，查法完全不同。

改完顺手把文档补一句，省得下次自己重新推一遍。

处理上按这个顺序：需要及时更新的资源把 max-age 降到分钟级；要每次验证就写 no-cache 保留 ETag；内容不变的资源用文件名哈希 配长 max-age；观察服务端 304 比例判断协商是否真的发生。

结果对不对很好判断，需要更新的资源每次访问都发条件请求 304 比例上升 用户能拿到新版本。