为什么Chrome请求CSS返回200 (from disk cache)而非304 Not Modified？

问题根因 #

标准HTTP协议中Cache-Control: no-cache的定义是：不得直接使用本地缓存响应请求，必须先将缓存标识提交到服务端校验有效性，校验通过后才能返回缓存内容（对应304状态码）。你遇到的现象是Chrome 93.0.4577.63版本的已知内核Bug导致的，不符合HTTP协议规范，具体触发逻辑如下：

• 当静态资源的本地缓存同时存在ETag或Last-Modified校验头、且服务端未返回must-revalidate的补充缓存规则时，普通刷新（F5）场景下Chrome 93会跳过服务端校验流程，直接读取磁盘缓存返回200 (from disk cache)
• 你观察到的请求头数量异常减少，是因为该请求根本没有发送到服务端，完全在浏览器本地缓存层完成响应，因此不会生成完整的HTTP请求头
• 该异常逻辑仅存在于Chrome 92~94正式版本区间，后续Chrome版本已经修复了该缓存规则解析漏洞

修复方案 #

全用户兼容方案（无Chrome版本限制） #

• 调整服务端CSS资源的响应头配置，将Cache-Control修改为no-cache, must-revalidate，显式要求所有场景下必须完成服务端校验后才能使用缓存，该配置在所有Chrome版本中均可被正确解析，不会出现跳过校验的问题
• 为静态资源添加内容哈希后缀（如style.f8e7d6.css），资源内容更新时哈希值同步变更，从根本上避免旧缓存被命中的问题

本地调试验证方案 #

• 使用强制刷新（Windows/Linux：Ctrl + F5，Mac：Cmd + Shift + R）触发完整资源请求流程，强制跳过本地缓存拉取最新资源，验证修复配置是否生效
• 如需复现异常场景，可确认当前Chrome版本是否为93.x区间，更换其他版本即可验证标准no-cache规则的表现是否符合预期

内容的提问来源于stack exchange，提问作者David Klempfner