1. 两个状态码背后的缓存真相打开浏览器开发者工具刷新一个页面在 Network 面板里你大概率会看到两类特殊的“灰色”请求一条显示着200 OK (from memory cache)另一条可能显示着304 Not Modified。很多前端新手看到这两个状态会懵一下——一个是 200看起来是成功的但又带了个括号里的小尾巴一个是 304不是“未修改”吗可这明明是刷新后的第一次加载怎么就没修改了说白了这两者都指向了同一个核心机制——HTTP 缓存。但它们的实现路径、触发条件和性能特点完全不同。作为天天跟浏览器打交道的前端开发如果搞不清楚这两者的区别排起缓存问题来很容易抓瞎优化页面性能时也会少了一把利器。这篇文章我会从浏览器实际工作的角度把这两个状态码拆开揉碎了讲清楚它们各自是怎么产生的浏览器为什么会做出不同的缓存处理以及作为开发者你需要怎么理解、怎么控制、怎么排查。文章里涉及到的内容主要围绕 Chrome 的行为展开因为日常开发中我们打交道最多的就是 Chrome但 Safari 和 Firefox 在核心逻辑上是一致的差异点我也会顺带说明。另外先声明一下这里说的缓存机制全部基于 HTTP/1.1 协议下的标准缓存语义也是目前绝大多数 Web 服务实际在使用的规则。2. 缓存机制的基础认知2.1 两个状态码到底差在哪先建立一个最直观的认知。下面这张对比表建议先收藏以后面试或者排查问题都能直接用。对比维度200 OK (from memory/disk cache)304 Not Modified是否发起网络请求不发起任何请求发起了请求但响应体不传输请求是否到达服务器没有完全在本地完成到达了服务器由服务器判定主要控制头Cache-Control、ExpiresLast-Modified / ETag浏览器分区强缓存本地缓存协商缓存条件请求性能开销几乎为零有一个 RTT 的开销响应体大小无直接读取本地无304 响应体为空常见场景刷新页面时图片、CSS、JS缓存过期后校验文件是否变化看完这张表你应该已经有了一个模糊的轮廓200 (from cache)是浏览器“自给自足”根本就没问服务器要东西而304是浏览器“先问一下服务器”服务器说“你没变用旧的吧”然后浏览器才安心地继续用本地缓存。2.2 强缓存和协商缓存的完整关系要想彻底理解上面的区别我们必须把 HTTP 缓存体系里最重要的两个概念摆出来强缓存和协商缓存。强缓存的思路是在第一次请求资源时服务器通过响应头告诉你“这个东西在某个时间点之前是新鲜的你直接用别问我”。浏览器收到这个时间点之后就会把资源存在本地。下次需要这个资源时只要还没过期就直接从本地读取完全不和服务器通信。这就是200 OK (from memory cache)或200 OK (from disk cache)的由来。协商缓存的思路则稍微复杂一点浏览器会在本地保存资源并同时记下这个资源的“验证凭证”——通常是Last-Modified最后修改时间或ETag实体标签。当强缓存过期之后浏览器不会直接放弃本地文件而是带着这个凭证去问服务器“我这个东西上次修改时间是 X现在还新鲜吗”服务器经过比对后如果确认没变化就返回一个304 Not Modified响应体为空。浏览器收到后继续使用本地缓存但需要考虑的是缓存的新鲜时间会被重置。用生活化的类比看强缓存相当于你家里囤了很多大米做饭前根本不看生产日期在一个保质期内随便用协商缓存相当于你在保质期过了之后还要先打个电话问一下商家“这批米过期没”商家说“没问题可以继续吃”你才敢下手。这里有一个很多人混淆的地方——304之后浏览器的缓存并不算“重新下载了文件”。它的实际效果是本地的文件继续使用但与缓存相关的计时器重新开始走。也就是说304 是一次“合法性确认”而不是“重新获取”。3. 浏览器如何区分 memory cache 和 disk cache3.1 存取位置与速度差异当我们看到200 OK (from memory cache)和200 OK (from disk cache)时其实看到的是强缓存的两个“物理存在”分支。memory cache就是内存缓存它是浏览器进程内维护的一块缓存区域特点是读取速度极快但它是非持久的——浏览器标签页关闭、进程结束这块缓存就没有了。它适合存放当前页面正在使用或刚刚使用过的资源尤其是图片、脚本这些体积较小但高频访问的内容。disk cache则是磁盘缓存持久化地存储在浏览器配置目录下的缓存文件中。它的读取速度比内存慢一些但优势是持久即使浏览器完全关闭后重启磁盘缓存依然存在。所以当你关闭 Chrome 再打开同一个网页很多资源会从 disk cache 里读取而不是全部重新下载。Chrome 在决定使用哪个缓存时会考虑资源的大小、最近的使用频率、当前浏览器内存的紧张程度等维度。一般来说较大的资源更倾向于磁盘缓存较小的、活跃的资源更容易命中内存缓存。另外对于在同一个页面会话里被反复引用的资源比如多张背景图只要内存中还放着浏览器就不会去磁盘里找。3.2 不同导航行为对缓存来源的影响这是很多人容易忽略但是实际工作中很重要的一点同样是从缓存里读资源你触发缓存的动作不一样读到的源头也可能不一样。我经常在排查问题时让同事做一个实验——在同一个页面上分别做四种操作在地址栏直接回车、按 F5 刷新、按 CtrlF5 强制刷新、通过链接跳转进入。Network 面板里看到的结果有很大差异。地址栏回车或者通过链接跳转属于“普通导航”浏览器拥有相当宽松的缓存授权。它甚至可以服务工作者Service Worker配合使用 memory cache 直接命中反应速度极快。F5 刷新则稍有不同。它会强制让浏览器对页面主资源做一次“协商”但对子资源仍然允许直接读缓存。你可以看到很多图片和脚本显示为200 (from disk cache)但 HTML 文档那个请求很可能就是304 Not Modified。CtrlF5 则是彻底绕过缓存的姿势浏览器会带上Cache-Control: no-cache这样的请求头去问服务器要最新的完整资源因此你基本看不到任何from cache的请求。这也是前端开发中排查“改了代码不生效”时的标准起手式。3.3 为什么刷新后有时候 200 from cache有时候 304很多开发者纳闷我按一下 F5加载同一个页面为什么有时图片全部是200 (from memory cache)有时却又出现一大片304原因在于 —— 从用户行为层面看F5 通常被认为是“刷新当前页面”浏览器会倾向于用更保守的缓存策略优先启用协商缓存但现代 Chrome 的策略也在不断微调很多时候页面主文档触发了协商但子资源还是直接走强缓存。而如果你在 DevTools 开着的情况下勾选了Disable cache那又是另一番场景——所有请求都会绕过缓存自然也就没有任何 from cache 或者 304 了。所以实际看到的结果跟你是否勾选了 Disable cache、资源自身的缓存头设置、资源加载的顺序和体积都有关系。不要死记硬背“F5 一定怎么样”记住它背后的策略倾向就好。4. 深入理解 304 的完整交互过程4.1 一次带条件请求的完整链路304 的处理场景本质上是浏览器发起了一个“条件请求”。这个完整的链路可以分为以下五步第一步浏览器发现一个资源的强缓存已经过期比如一个 CSS 文件的Cache-Control: max-age60而距离上次缓存已经过去了 120 秒。第二步浏览器并不会直接丢缓存而是查看本地缓存的响应头里是否包含了Last-Modified或ETag字段。如果包含它会构造一个请求把这两个字段对应的值作为请求头带上去。Last-Modified对应的请求头是If-Modified-SinceETag对应的请求头是If-None-Match。第三步请求到达服务器。服务器收到这个带条件的请求后会拿着这两组值跟服务器上的文件做比对文件最后修改时间是否晚于If-Modified-Since的值当前文件的实体标签是否和If-None-Match一致第四步如果文件确实没有变化服务器直接返回304 Not Modified响应体为空。配合这个状态码服务器通常还会带上新的Cache-Control和过期时间让浏览器重新算一遍缓存周期。第五步浏览器收到 304 后从本地缓存里读取响应体并且依照新的缓存指令继续缓存该资源。这个过程真正的性能意义在于304 响应虽然没有响应体但它仍然需要走一遍完整的 HTTP 请求-响应往返。也就是说它还是有网络开销的只是这个开销远小于传输完整文件。如果是 CDN 加速的场景这个 RTT 可能只有几十毫秒但如果是弱网环境304 的等待时间依然可能让人明显感知到。4.2 ETag 和 Last-Modified 的相爱相杀聊到协商缓存就绕不开ETag和Last-Modified这对“双娇”。很多初学者会问有Last-Modified就够了为什么还要搞出个ETag这是因为Last-Modified存在几个天然的软肋第一它的精度只到秒。如果一个文件在同一个秒级时间窗口内被修改了两次Last-Modified是无法感知这种变化的而ETag通常是基于文件内容生成的哈希值任何字节级的修改都能被捕捉到。第二某些服务器对Last-Modified的处理并不可靠尤其是负载均衡后面有多个后端节点的时候不同节点的文件时间戳可能有微小出入容易造成缓存验证的误判。第三动态生成的响应可能本身就没有一个稳定的“修改时间”概念比如一个由用户状态拼装出来的接口每次生成的时间都可能不同ETag这种基于内容特征的指纹反而更准确地反映出“到底内容有没有变”。但ETag也不是银弹。它的计算需要额外的 CPU 资源尤其对于超大文件生成一个质量较高的 ETag 并不是零成本的。而且某些实现粗糙的ETag可能仅仅是基于文件的 inode 和修改时间计算的也会出现精度问题。在实际开发中我的建议是服务端最好同时输出Last-Modified和ETag。浏览器在发起条件请求时会同时带上If-Modified-Since和If-None-Match。在这种情况下按照 HTTP 规范服务器应该优先以If-None-Match为准只有这个值不存在或校验通过时才回头去看If-Modified-Since。这种双保险的做法既照顾了兼容性又尽可能保证校验的准确性。4.3 304 一定是好事吗回答这个问题之前先要分清一个概念——304对性能的影响远比200 (from cache)大。这样说可能有点反直觉因为大多数人的印象里304 既然是“没有传输数据”那应该是性能最优才对。但实际上从用户体验的角度来看一次200 (from memory cache)可能只需要不到 1ms 就完成了因为它完全在本地发生。而一次304至少需要一次完整的网络往返。如果你们的服务器在海外用户在国内这一来一回可能就是几百毫秒。所以更优的缓存策略不是“永远 304”而是尽量让资源直接命中强缓存从一开始就不走到“协商”那一步。这就是为什么很多公司对静态资源采用“文件名哈希 长缓存”方案的原因——文件没变文件名不变缓存时间很长直接 from cache文件变了文件名变了相当于全新请求根本用不上协商缓存。只有当资源真的可能随时变化、但又不想每次传输完整资源时比如某些业务接口304 才是一个合理选项。5. 缓存验证与实战控制5.1 你真的会看 Network 面板吗工欲善其事必先利其器。在实际排查中不会看 Network 面板的细节很容易被表象迷惑。我建议你打开 Chrome DevTools把 Network 面板的卡片视图具体来说是在请求列表的表头右键配置为显示多个关键列。重点关注这几个字段Name、Status、Type、Size、Time以及Waterfall时间轴。Status是核心直接查看请求是哪一类响应Size列则非常有意思——它会同时显示真实传输的大小和缓存来源。比如一条请求显示为200 OK (from disk cache)Size 列会直接显示(from disk cache)表明没有走网络。而一条304 Not Modified响应Size 列会显示一个很小的值比如 200B 左右因为传输的只有响应头。如果你看到一条 304 的 Size 列数值很大那说明你的缓存配置很可能出了问题。Waterfall 时间轴同样有价值。200 (from cache)的请求在时间轴上几乎是一条竖线区间极窄304的请求则能看到明显的等待服务器响应的时间块。另外一个非常实用的功能是点击任意一个请求切到 Headers 标签页能看到完整请求头和响应头。排查缓存问题时的标准动作就是看这里——检查响应头里有没有Cache-Control、Expires、Last-Modified、ETag这四兄弟再对照请求头里有没有If-None-Match或If-Modified-Since基本上就能还原整条缓存决策链。5.2 让缓存为你所用常用策略速查每个项目都需要根据自己的资源类型制定缓存策略。下面是我在实际项目中常用的几套标准配置涵盖了不同资源类型的最优解。资源类型推荐策略解释HTML 页面Cache-Control: no-cache每次都允许缓存但必须回源校验。这样保证内容更新能快速生效同时又利用缓存省下传输体静态图片/字体Cache-Control: public, max-age31536000, immutable配合文件名哈希一年内不用回源直接强缓存命中CSS/JS 构建产物Cache-Control: public, max-age31536000, immutable内容变化即文件名变化用长缓存最大化命中率API 接口数据Cache-Control: no-store或短max-age根据业务实时性要求决定但绝大多数 PUT/POST 类接口建议 no-store第三方类库文件Cache-Control: public, max-age604800一周的缓存周期兼顾更新与性能关于immutable这个指令很多人不知道它是干什么的。它是 HTTP 缓存规范中的一大强化指令告诉浏览器这个资源在过期之前绝对不会变化你可以放心大胆地使用缓存刷新页面时也不必发送条件请求去验证。Chrome 在支持该指令后对于设置了immutable的静态资源即使是用户在地址栏主动刷新也不会产生任何验证请求直接从缓存里读取。5.3 前端代码层面如何主动干预缓存有时候不完全是服务端配置的问题我们还可以在前端代码里做很多事情来配合缓存机制。最重要的一招就是构建产物的内容指纹。无论你用 Webpack、Vite 还是别的构建工具都应该确保生成的 CSS/JS 文件名带上内容哈希比如app-8f3d2a9b.js。简单理解只要文件内容变了哈希就变文件名就变浏览器就会把它当作一个新请求来加载旧缓存直接被跳过。第二招是合理控制 Service Worker 的缓存策略。Service Worker 作为浏览器与网络之间的“代理”能让我们实现比 HTTP 缓存更精细的控制。比如你可以对某些接口做“网络优先、缓存兜底”对静态资源做“缓存优先、后台更新”还可以在 Service Worker 里主动清理过期缓存。但 Service Worker 也是一把双刃剑如果版本控制不当很容易出现“我怎么改都不生效”的惨剧。我见过太多同事被 Service Worker 坑到怀疑人生最后只能硬着头皮清掉整个站点数据。所以使用 Service Worker 缓存的前提是你已经想清楚了完整的更新和失效机制。第三招是通过fetch的cache选项来自定义单个请求的缓存行为。fetch(xxx, { cache: no-store })可以直接忽略本地缓存cache: reload则会强制走一次完整的网络请求cache: force-cache表示尽量使用缓存哪怕它已经过期也能在本地找到就用。这些细粒度控制在调试接口时非常好用。5.4 常见坑位静态资源更新了页面却纹丝不动这类问题几乎是每个前端都会遇到的高频到值得单独写一节。排在第一位的是——你对旧文件发起了一个协商请求但服务器返回了 304而事实上文件已经更新了。这听起来很离谱但确实可能发生。原因通常出在服务器对If-Modified-Since的处理上有些服务器配置不对会用“容器启动时间”或者“默认值”去跟请求头对比导致误判。解决办法很粗暴——在测试环境中建议直接把静态资源的缓存头全部改成no-cache等联调完成、发布前再切换成长缓存策略。第二个常见坑是Nginx 的缓存配置与 CDN 的缓存配置“打架”。比如你在 Nginx 层设置了Cache-Control: max-age0, must-revalidate而 CDN 节点却强行缓存了几个小时。结果就是 CDN 缓存了老文件源站更新的内容完全出不去。排查这种问题时需要顺着用户侧看到的响应头一层层溯源确认到底哪一层的缓存头在起作用。第三个坑是DevTools 里的 Disable cache 选项。这个选项在 DevTools 打开的状态下是默认为勾选的吗不是但很多人多年前手动勾上后就忘了。要命的是只要 DevTools 面板开着这个选项就会生效所有请求都不走缓存。而被它坑过的场景通常是明明加了缓存头刷新页面却总是显示从网络加载完整资源。如果你遇到这种情况第一反应就是去 Network 面板下面找那个 Disable cache 前面的复选框。第四个坑也有意思——浏览器的“自适应缓存”行为。Chrome 在判断资源的使用频率后可能会临时改变某些资源的缓存策略。比如一个资源你连续访问了几十次它会自动把有效期扩展即使响应头写的是短缓存它可能也会在一次生命周期内继续使用。这种行为不完全受开发者控制但通常只在非常极端的场景下才能被察觉。6. 200 from cache 与 304 的实战排查方法6.1 一个标准化的缓存问题排查流程面对“页面资源不更新”或者“每次都重新下载资源”这两个反向的问题我的排查流程通常是固定的五步分享出来供你参考。第一步打开 Network 面板确认现象。先看目标请求是200、304还是from cache同时看一眼 Size 列判断资源有没有走网络传输。第二步查看请求头和响应头判断资源命中了哪一层缓存。关注Cache-Control、Expires、ETag、Last-Modified。这里要特别注意——如果你看到一个200状态码但响应头里没有缓存相关字段说明服务器根本没有开启缓存策略。第三步模拟多种导航行为。分别通过地址栏回车、F5 刷新、CtrlF5 强制刷新观察差异。如果地址栏回车是 from cache但 F5 变成了 304说明强缓存配置没问题问题可能出在用户对刷新操作的预期上。第四步排查中间的代理层。把 CDN、网关、反向代理逐层检查确认最终返回给浏览器的响应头是源站的还是某一层代理篡改过的。第五步切换到不同浏览器验证。Chrome 的缓存行为跟 Safari 略有差异如果只有特定浏览器出现问题优先考虑浏览器特有行为而非服务器配置问题。这套流程我用了很多年基本能覆盖 90% 的缓存问题场景。当然真正执行的时候每一步都需要借助浏览器的开发者工具以及 curl 之类的命令行工具才能看得足够细。6.2 用 curl 直接模拟条件请求有时候浏览器开发者工具会有它的“自动适配”不方便暴露原始行为。此时用 curl 直接和服务器对话往往是更干净的分析方式。比如你要手动模拟一次带If-None-Match的条件请求可以这样写curl -i -H If-None-Match: 5e5a2f6-1a2b3c https://your-site.com/app.js如果服务器返回304 Not Modified说明 ETag 校验通过资源没有变化。如果返回200 OK并携带完整响应体说明资源已经变更或者 ETag 配置失效再看返回的响应头里的 ETag 与请求时带过去的是否一致就能精准定位问题出在哪个环节。类似的还可以模拟If-Modified-Sincecurl -i -H If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT https://your-site.com/app.js这个方法在排查 CDN 层是否透传源站缓存头时尤其好用。先对源站发起请求看响应头再对 CDN 域名发起同样的请求对比两者之间缓存头的差异结果一目了然。6.3 借助 DevTools 里的 Application 面板检查缓存内容还有一个很少人真正利用起来的地方就是 DevTools 的 Application 面板。切换到Application标签后左侧会有个Cache Storage和Back/forward cache或者不同版本下显示为Back-forward Cache等条目但更实用的其实是Storage下的Cache Storage和Network相关的访问记录。如果你开发了 Service Worker那么从 Cache Storage 里可以看到当前 Service Worker 正在使用的缓存 key 列表以及每个缓存里存放的请求和响应。对于排查“Service Worker 缓存了不该缓存的文件”这类问题这是最快的路径不用抓包就能直观看到缓存池里的内容。除此之外Application 面板最下方的Clear storage按钮是彻底清理站点运行数据的快捷入口。按一下它清掉 Local Storage、Session Storage、IndexedDB、Service Worker、Cache Storage几乎相当于浏览器第一次访问这个站点的基础状态。这个操作在日常排查中极其常用比你自己去设置里清 Cookie 要高效得多。7. 缓存策略设计的进阶思考7.1 从“缓存命中”到“过期一致性”的全局视角讲了这么多底层机制最后想把视角拉高一点——缓存设计的本质其实是在“新鲜度”和“性能”之间做权衡。作为前端开发者我们经常只盯着自己的静态资源看但一个完整的产品往往包含大量动态内容。这些内容如果全部使用 no-store用户体验会很差如果全用长缓存又可能带来数据不一致。所以真正成熟的做法是给系统中的资源分门别类建立一套全链路的缓存策略矩阵。一个基础但有效的思路是内容越稳定缓存时间越激进内容越动态缓存验证越频繁。拿一个典型的内容站来举例框架级文件Vue/React 运行时、基础组件库→ 一年长缓存业务代码构建产物 → 内容哈希命名长缓存文章页 HTML → no-cache每次协商用户头像 → 一周到一月不等的强缓存用户信息接口 → 短缓存或者不缓存这套分级体系能保证大部分流量走在“零成本”的强缓存命中路线上又不会让用户看到明显过期的数据。7.2 304 不是原罪但过度 304 需要警惕前面说过304 依然有网络开销。如果一个页面上出现了几十个 304那也并不是一个值得夸耀的“缓存命中”相反它意味着你的强缓存设置没有让这些资源“活得更久”。这里有个判断标准对于静态资源理想状态应该是非常高的强缓存命中率而不是 304 满天飞。如果你的网站在 Network 面板里到处飘着 304要么是 HTML 文档本身的协商行为要么是静态资源的缓存时间设置太短了。另外要警惕“304 风暴”对服务器资源的消耗。虽然 304 响应比 200 便宜得多但每一个 304 依然意味着一次服务器处理、日志写入、连接管理等开销。在高并发场景下这些开销仍然可以被放大。把 CSS/JS 的缓存时间拉长、配合内容哈希来更新才是静态资源的最优解动辄 304 的策略并不值得效仿。7.3 304 与 SEO 的关系这一节可能有点“超出前端本职”但我觉得很有必要提一嘴——缓存的设置会间接影响到搜索引擎对站点质量和访问速度的打分。搜索引擎的爬虫同样遵守 HTTP 缓存语义。合理地使用缓存可以让爬虫在有限的时间预算里爬取更多有效页面减少无效的资源下载。尤其对于大站利用Last-Modified和 ETag 实现更高效的增量抓取降低服务器压力对提升整体 SEO 表现有正面作用。当然做 SEO 不是简单地让所有资源都 304 就行的还要考虑relcanonical、sitemap等更细致的配合。但至少你要知道缓存策略的影响范围并不仅仅停留在浏览器控制台里。8. 个人经验总结与建议做前端这几年我在缓存上踩过的坑确实不少。有些坑属于知识盲区比如早期我根本不知道from memory cache和from disk cache有什么区别直到有一次线上问题需要精确判断一个文件到底从哪里被加载的才逼着自己去把这块彻底弄通。有些坑则属于实践细节比如我一度非常迷信no-cache觉得这个指令足够安全结果发现它意味着每次都要走网络请求页面速度惨不忍睹后来才理解no-cache并不是“不缓存”而是“使用前必须验证”。我现在习惯性的做法是在本地开发环境里把 304 的原理和 DevTools 的表现形态玩得滚瓜烂熟遇到问题先问自己一句——“这个请求到底该不该走网络”然后顺着这条链路从响应头到请求头逐项排查。这套方法帮助我解决了不少同事求助的疑难杂症。如果你要系统地提升这块能力我建议按这个顺序去实践先彻底理解强缓存和协商缓存的原理再亲手用 Node 或者任意后端框架写几个接口配置不同的缓存头用浏览器和 curl 观察它们的真实表现。等到你能够预期某个请求会以什么状态返回这件事就算是真正掌握了。缓存不是 Web 性能优化的全部但它是最基础、最容易见效的一环。把200 OK (from memory/disk cache)和304 Not Modified彻底吃透你离一个更“懂浏览器”的前端就更近了一步。