浏览器缓存机制全解析：从强缓存到发布策略

从“把页面部署上线了用户还在喊旧页面”这个经久不衰的话题开始聊吧。我在给一个管理后台做版本升级时遇到过这种情况前几分钟我还在本地确认新版样式没问题结果运维一说客户端反馈没看到变化我打开浏览器检查Network 面板里明明白白显示资源是从 disk cache 里拿出来用的请求根本没到服务器。那一刻我意识到“缓存机制”不是看几篇科普就能掌握的它需要用真实的请求链路去理解尤其是各种响应头组合、缓存位置的优先级、验证器的判定逻辑以及它们如何在实际发布场景里制造出“更新了个寂寞”的错觉。这篇内容我不会把浏览器缓存当八股文背给你听而是把链路拆开讲讲浏览器到底怎么决定“这个资源我用旧的还是去服务器拿新的”以及我们在配置响应头、改版本号、调 DevTools 时最常见的误区和靠谱做法。适合的读者包括前端开发者、接口设计者以及任何被“清了缓存还是没变化”折磨过的人。看完之后你会有一套完整的排查思路和策略设计方法不用再靠清缓存碰运气。1. 资源请求的“缓存命中-未命中”决策链1.1 缓存在浏览器里的真实价值先明确一个前提浏览器的 HTTP 缓存本质上是一个“避免重复下载资源”的机制。当你在一个页面里加载了十几张图片、几份 CSS 和 JS 文件下一次再打开同一个页面时如果这些字节全部重新走一遍网络消耗的是用户的带宽、运营商的时间以及服务器的压力。而浏览器缓存做的事情是在满足一定条件时直接把本地存储的资源当作响应返回让网络请求次数降为 0。这个“避免重复”的价值在小屏幕上尤其明显。移动端网络不稳定、流量有成本一次页面打开如果能省下几百 KB 的重复传输体验差距是肉眼可见的。这也是为什么缓存策略会直接影响 Web 性能评分比如 Lighthouse 里的 “Serve static assets with an efficient cache policy” 这一项——它考的就是你有没有给静态资源配好缓存头。1.2 浏览器找缓存的顺序不是只有“内存”和“磁盘”两个地方很多人以为浏览器缓存只是“内存里的缓存”和“磁盘上的缓存”二选一实际上现代浏览器的缓存体系分了好几层。以 Chrome 为例一次资源请求的查找顺序大致是Service Worker 缓存如果当前页面注册了 Service Worker并且 fetch 事件被拦截了请求首先会被交到 Service Worker 手里。它可以走 Cache Storage API也可以自己决定要不要回源。这一层是应用层面的缓存普通 HTTP 缓存规则控制不了它。Memory Cache内存缓存这是最快的缓存保存着当前会话中已经加载过的资源。它的特点是速度极快但生命周期很短页面标签关闭、内存压力大时都可能被清掉。你“刷新”页面时命中的经常就是这一层。Disk Cache磁盘缓存这是持久化缓存资源会以文件形式写到磁盘上。关闭浏览器再打开只要缓存没过期依然可以命中。它是浏览器在多个标签页、多次会话之间复用的主力缓存。Push CacheHTTP/2 服务端推送时使用的缓存层资源被推送给浏览器后可以在后续请求中直接命中。这一层日常开发感知不强但如果你在做 HTTP/2 相关优化需要了解它的存在。整个查找链路有一个很重要的特点只要在某一层命中了满足条件的资源请求就不会继续往下走。也就是说如果内存缓存里已经有一个有效资源浏览器就不会再去读磁盘更不会发起网络请求。这个“只要命中就短路”的特性决定了我们排查问题时必须分清资源到底是从哪一层缓存出来的否则很容易误判。1.3 一个表格看明白缓存位置的差异缓存层存储位置命中速度生命周期典型命中场景Service Worker浏览器存储Cache Storage快但受 JS 逻辑影响由代码控制离线应用、纯前端可控的缓存策略Memory Cache内存最快当前会话内标签关闭后可能失效页面刷新、页面内重复资源Disk Cache磁盘较快但比内存慢持久直到过期或被清除重新打开浏览器、多次访问同一站点Push Cache内存/连接级快会话或推送连接内HTTP/2 推送资源的二次利用我实际排查问题时会把“命中了哪一层”当作第一条线索如果刷新后资源来自 memory cache说明当前会话缓存是有效的如果冷启动后来自 disk cache说明缓存策略已经持久化生效如果来自 service worker那就得去翻 Cache Storage 里的代码逻辑不能用普通 HTTP 缓存思维去硬套。2. 强缓存与协商缓存决定“要不要发请求”的两套规则2.1 强缓存浏览器自己就能拍板不需要找服务器确认强缓存的意思很简单资源在有效期内浏览器直接从本地缓存里拿根本不发出网络请求。决定强缓存是否有效的核心响应头是Cache-Control它最常用的几个指令包括max-age31536000资源从响应时间算起可以新鲜保存 31536000 秒一年。在有效期内再次请求直接命中缓存。public/privatepublic 表示任何节点包括 CDN、代理都可以缓存private 表示只能浏览器私有缓存中间代理不能缓存。对于带用户信息的接口一般用 private。no-cache名字像“不缓存”但实际意思是“可以缓存但每次使用前必须先去服务器验证一下资源是否仍然新鲜”。也就是说它不会直接用本地缓存但协商通过的话依然可以不传响应体。no-store这个才是真正的不缓存。直接禁止浏览器和中间代理保存资源适合含有敏感信息的响应。must-revalidate资源过期后必须重新验证不能继续使用过期资源。stale-while-revalidate过期后可以先返回旧的缓存给页面同时在后台发起验证更新缓存是一种“先用旧值再说新值来了下次用”的策略。还有一个历史遗留的响应头Expires它是 HTTP/1.0 时代的产物值为一个绝对时间。现在它基本被Cache-Control取代了但仍然有不少老系统在用它。两者同时出现时以Cache-Control为准。2.2 协商缓存不发整个资源了但还是要问一下服务器当强缓存过期了或者资源本身就带了no-cache指令浏览器需要去和服务器确认资源是否变了。这个确认过程就是协商缓存它的特点是请求还是要发出去但可以带着验证信息去问服务器如果服务器判断资源没变就返回 304 状态码不返回响应体浏览器接着用本地缓存。协商缓存的核心是两个验证器Last-Modified配合If-Modified-Since。服务器第一次返回Last-Modified: Wed, 21 Aug 2024 12:00:00 GMT浏览器下次请求时带上If-Modified-Since内容就是上次拿到的这个时间。服务器拿这个时间跟资源实际修改时间比较如果资源没有比这个时间更晚的修改就返回 304。ETag配合If-None-Match。服务器给资源生成一个内容相关的哈希标识比如64b9a2e0-1a2b3c浏览器下次请求时带上If-None-Match。服务器拿这个值和当前资源的 ETag 比较相同则返回 304不同则返回 200 和新内容。当响应头里同时有ETag和Last-Modified时绝大多数传统实现会优先检查ETag因为内容哈希的粒度比“秒级修改时间”更细能避免同秒内多次修改却判断资源未变的情况。实际部署时我建议尽量两个一起配让兼容性和准确性都有保障。2.3 同一份响应里多个缓存指令谁说了算这里有个很重要的认知HTTP 缓存并非“一个头决定一切”而是多个头组合、再配合请求上下文共同作用。常见优先级是这样排列的Cache-Control里的指令优先级最高尤其是max-age与no-store这类显式指令。如果Cache-Control不存在退回看Expires。ETag和Last-Modified是验证器它们决定的是“强缓存失效后协商缓存怎么校验”不影响强缓存本身的有效期判定。在一个请求里如果浏览器本身加了Cache-Control: no-cache或Pragma: no-cache一般是强制刷新时干的那么服务器设置的max-age也会被忽略强制走协商验证。所以判断一个资源的完整缓存命运不能只盯着某个头看要看这组响应头作为一个整体给了浏览器什么信息。比如HTTP/1.1 200 OK Content-Type: application/javascript Cache-Control: public, max-age3600 ETag: abc123后面的 3600 秒内是强缓存过期后浏览器会带If-None-Match: abc123去协商。如果资源内容没变服务器回 304浏览器继续用旧的如果变了就回 200 和新资源。HTTP/1.1 200 OK Content-Type: text/html Cache-Control: no-cache ETag: html-v1.2这份 HTML 不会被强缓存直接使用每次请求都会去服务器验证。验证通过时返回 304验证不通过时返回新 HTML。这类配置特别适合页面文档本身它要保证用户能拿到最新版本但又希望能省掉重复下载 HTML 内容的流量。3. 深入验证细节ETag、修改时间与 304 的边界情况3.1 同秒多改的问题为什么 Last-Modified 容易踩坑我在实际项目里遇到过这样一个问题一个后端服务在极短时间内连续生成了两个内容不同的 JSON 文件因为文件系统记录的修改时间精确到秒两次修改都落在同一秒里Last-Modified的值一样。浏览器拿着旧文件的If-Modified-Since来验证服务器一看“文件的修改时间没有晚于这个时间”就直接返回了 304但实际上内容已经变了。结果用户那边的接口数据一直是旧的排查了大半天。这个案例说明Last-Modified是一个粒度较粗的验证器。它只能精确到秒级而且服务器之间的时钟也不一定完全一致。ETag在这种场景下就体现出优势——它直接对比内容指纹只要字节序列变了哈希就会变协商结果绝不会因为时间精度问题产生误判。所以我后来给团队定了一条规矩凡是可能频繁变更、且对一致性要求高的资源一定要用 ETag 做协商验证Last-Modified 可以作为辅助信息保留但不要单独依赖它。3.2 协商缓存里一个最常见的 304 流程复盘把协商流程完整走一遍有助于理解浏览器到底在“问什么”。假设我第一次访问页面服务器返回了HTTP/1.1 200 OK Cache-Control: public, max-age60 ETag: W/abc-v1 Last-Modified: Mon, 11 Nov 2024 10:00:00 GMT Content-Type: image/png60 秒内我再请求同一个 URL浏览器直接命中强缓存连请求都不发。60 秒后请求会带着验证头发出去GET /images/logo.png HTTP/1.1 If-None-Match: W/abc-v1 If-Modified-Since: Mon, 11 Nov 2024 10:00:00 GMT服务器看到If-None-Match等于当前资源的 ETag且修改时间没有变化就返回HTTP/1.1 304 Not Modified注意304 应答里不会带响应体只是告诉浏览器“可以继续用你本地那份”。浏览器收到 304 后把本地缓存的资源正常交给页面使用。整个交互中网络传输的只有头部信息节省了完整资源的字节量。3.3 强缓存与协商缓存同时失效的边界还有一种多管理员场景需要注意的边界资源确实变了但服务器返回的新响应里没有带任何新鲜度信息。这种情况浏览器通常无法判断资源该缓存多久可能会根据自己的启发式算法缓存一小段时间也可能直接不缓存。我在开发环境见过某些后端接口返回时忘记设Cache-Control浏览器用管理逻辑把它缓存了几分钟结果前端联调时改了数据却看不到变化。一个可靠实践是当资源不该被缓存时后端明确返回Cache-Control: no-store当资源允许短时间缓存时明确返回max-age。别把缓存决策交给浏览器的“猜”。另外要注意Vary响应头的存在。如果服务器返回了Vary: Accept-Encoding说明缓存键需要包含请求头里的Accept-Encoding才能匹配Vary: Cookie则意味着不同 Cookie 的用户会各有各的缓存。Vary设得太宽会降低缓存命中率设得太窄又可能导致缓存错发给不同用户这是一个需要结合业务权衡的点。4. 发布策略与缓存策略怎么配合从指纹文件到 HTML 不缓存4.1 为什么“覆盖同名文件”是缓存优化的大忌很多小型站点发布时还是用最原始的方式直接把 js/app.js 上传到服务器同名覆盖。问题来了浏览器本地可能已经缓存了旧的 app.js而且缓存策略还可能是max-age86400。用户当天已经访问过站点之后几天内打开看到的永远是旧版文件即使服务器上的文件已经变成了 v1.2浏览器也不知道因为强缓存命中时根本不会问服务器。真正可持续的解法是资源指纹化。所谓指纹化就是在文件名里加入文件内容哈希比如app.8f3b2a.js。文件内容变了哈希就变文件名也变URL 就变了。新的 URL 在浏览器眼里是全新资源不存在旧缓存命中的问题而旧 URL 的缓存即使还在有效期也不会对页面造成影响因为 HTML 里已经引用了新 URL。这种策略配合给静态资源设置一个很长的Cache-Control: public, max-age31536000一年完全没问题因为资源一经发布就不会再原地修改要更新就生成新文件名。一年内用户再次访问站点这些带指纹的文件可以直接命中缓存连协商验证都省了。4.2 HTML 文档永远走“每次验证”的路线跟静态资源不同HTML 页面文档是所有子资源引用的入口。如果 HTML 被强缓存了它里面引用的资源 URL 就被钉死在旧版本上那后面指纹化做得再好也没用因为浏览器根本拿不到新 HTML 里的新 URL。所以我推荐的通用组合是主文档HTML、入口文件Cache-Control: no-cache配合ETag或Last-Modified。每次请求都会向服务端验证但 304 时的流量开销很低。带哈希的静态资源Cache-Control: public, max-age31536000, immutable。一年不变刷新页面也不去验证。不带哈希的静态资源比如某些第三方脚本直接引用的路径建议Cache-Control: public, max-age0, must-revalidate让浏览器每次都用协商缓存确认一遍。immutable是辅助指令。设置它之后即使用户在地址栏回车刷新页面Chrome 也不会对带指纹的资源做重新验证。不过注意immutable目前不是所有浏览器都完全支持但它的价值在于让强缓存更彻底地生效不影响不支持的浏览器走常规缓存逻辑。4.3 CDN 与代理缓存缓存作用域不止于浏览器浏览器缓存讲的是一端之事但实际部署中还会遇到 CDN 和反向代理这层共享缓存。s-maxage就是这个作用域下的控制指令。如果一个接口同时设置了Cache-Control: public, max-age60, s-maxage300浏览器看到的是 60 秒新鲜CDN 看到的是 300 秒新鲜。注意CDN 缓存的是服务器响应浏览器缓存的是用户本地两者策略完全可以不同。这里常见的坑是有人只在 CDN 上开了缓存却忘了给静态资源设置合理的浏览器侧Cache-Control结果咔咔打在 CDN 上用户本地每次还是要回源拿一遍白白浪费了网络传输。做性能优化时两条链路都要确认。4.4 移动端与隐私模式下的行为差异移动端的浏览器内核五花八门缓存策略的实现在细节上有差异。比如部分国产浏览器对Cache-Control的某些指令支持不够完善或者因为节省流量等原因自己加了“无图模式”“缓存加速”导致明明没配缓存规则资源也被缓存了。隐私模式无痕模式下Chrome 等浏览器通常不允许磁盘缓存只会用内存缓存因此会话结束缓存就清空了用户在无痕模式下看到旧资源的概率比正常模式下更低但也别因为无痕刷新“万无一失”就忽略对缓存头正确性的排查。在开发调试时如果调用了fetch且cache选项被设置成no-store即便服务器响应头允许缓存浏览器也不会存。所以看到“接口明明设置了 Cache-Control 但 Network 面板里始终没有缓存命中”时先检查的是代码层的请求配置而不是怪浏览器。4.5 常见“发布后没更新”场景的根因定位遇到用户反馈“新版没看到”我的排查顺序通常是先看 HTML 是否被缓存。如果是看 HTML 的响应头。如果 HTML 本身被max-age强缓存先解决这个否则改什么都白发。再看子资源是否带指纹。如果文件还是app.js这种固定名改为指纹化命名。检查 Service Worker。有时候不是 HTTP 缓存的问题而是 Service Worker 用 Cache Storage 存了旧资源并且采取了 cache-first 策略根本不请求网络。这需要到 Application 面板的 Cache Storage 里手动看缓存条目。看 CDN 是否回源了新文件。CDN 缓存未过期实际用户拿到的就是 CDN 上的旧文件这时候清浏览器缓存没用得刷新 CDN 缓存。排查顺序对了90% 的“缓存玄学”都能变成可定位的具体问题。5. 用 DevTools 把缓存问题从玄学变成科学5.1 Network 面板里那些信息的准确含义Chrome DevTools 的 Network 面板有一个“Size”列它会显示资源到底来自哪里。常见值有200 (memory cache)命中内存缓存请求未发出。200 (disk cache)命中磁盘缓存请求未发出。200 (service worker)由 Service Worker 返回。304已经发出请求服务器验证后确认资源未变从缓存中读取响应体。200从网络正常加载服务器返回了完整资源。有一种容易混淆的情况是状态码是200但 Size 列显示(disk cache)这是“绕过了网络请求由本地缓存直接返回”的意思而返回304的意思是“网络请求发送出去了但服务器用头部信息表示资源没变”。两者都是缓存生效但请求链路的参与程度完全不同。搞清这两个状态就能判断强缓存和协商缓存分别有没有起作用。另外Network 面板顶部有一个“Disable cache”复选框。勾选它之后打开 DevTools 的状态下页面刷新会绕过 HTTP 缓存强制走网络验证。注意这个设置只在 DevTools 打开时生效你关掉 DevTools 再刷新就恢复了。5.2 一个完整的缓存问题排查链路我在排查“缓存导致页面不更新”时执行过下面这套步骤分享出来供参考打开 DevTools切换到 Network 面板刷新页面。找到未更新的资源看 Size 列来源。如果是 memory/disk cache说明强缓存命中。复制资源 URL在同一个标签页打开并查看完整响应头确认Cache-Control里的max-age、no-store、no-cache等指令到底怎么写的。如果响应头配置看起来合理但实际行为不对考虑是不是请求本身带了别的缓存相关 header比如Cache-Control: no-cache的 fetch 选项。如果没有 Service Worker到 Application 面板看 Cache Storage 是否为空有 Service Worker 时还要看它的 fetch 拦截逻辑。这套流程做下来绝大多数缓存问题都能定位到具体原因。我最常见到的根因是服务器开发只设了一个指向index.html的Cache-Control: max-age86400整个入口每天都在变却被浏览器按天缓存用户自然永远见到旧的。5.3 手动验证缓存策略正确性的几个小技巧用 curl 模拟协商缓存先请求一次资源保存ETag然后带上If-None-Match再请求一次看是否返回 304。这个验证不依赖浏览器能直接确认服务器行为。在 Network 面板里选 “Clear browser cache”方便模拟首次访问。修改响应头后别只刷新页面部分浏览器对同一个 URL 的刷新会带上条件验证如果本地缓存没过期刷新也不一定能拿到新头。最稳妥的是用无痕窗口或者清掉该站点缓存再看。用 Application 面板手动查看键值对条目不同框架的本地缓存可能不是通过 HTTP 缓存实现的而是放进localStorage或indexedDB这时要在 Application 面板里逐个核对存储数据别只盯着 Cache Storage 看。5.4 排查时容易被忽略的“请求头”因素有时候问题不在响应头而在请求头。比如上面说的 fetch 请求手动设置了cache: no-store或者表单提交等历史模式触发了缓存规避行为都会导致“明明服务器给了很久的有效期浏览器还是每次请求”。再看Range请求如果浏览器发起了带Range的分段请求资源只有部分字节被缓存强缓存判定逻辑也更复杂。总之DevTools 里请求头、响应头两个面板都要看才能得出完整结论。最后聊点我自己的“缓存操作心得”我现在开发调试时有一个习惯改完静态资源后用的不是“强刷”而是“无痕窗口加 Network 面板”。因为强刷只是绕过本地强缓存但 HTTP 协商验证仍然存在无痕窗口每次都是全新的存储上下文能确保我看到的是绝对真实的网络返回。这个习惯帮我避免了不少“本地看着行换了机器就翻车”的假象。另一个心得是给资源设计缓存策略时先想清楚它的身份。入口文件、动态接口、带指纹的静态资源这三类资源的缓存策略是完全不同的不要混为一谈。入口文件用 no-cache 保新鲜静态资源用长缓存保性能动态接口按场景决定要不要缓存。每类资源找准自己的角色整个站点的缓存行为就会变得有规律可循出问题的时候也能很快找到线索。说到后续可以再扩展的方向我觉得有两个一是 Service Worker 的缓存策略设计比如stale-while-revalidate怎么在离线场景里进一步提升体验二是 HTTP/2 和 HTTP/3 下的缓存键变化尤其是连接复用之后浏览器对并发请求的缓存判断有什么细节差异。等我把这两个方向的实践经验再攒多一些后面可以继续分享。