你有没有遇到过这种情况前端代码刚改完兴冲冲地刷新页面结果样式还是旧的改了个寂寞。骂完浏览器缓存按 CtrlF5 强制刷新看到新样式才松了口气。这个问题背后其实是资源加载与缓存机制在起作用。今天这篇原理篇我不讲框架、不讲组件就把从浏览器收到 HTML 开始到静态资源被加载、缓存、命中的完整链路拆开一层层讲清楚。无论你是刚入行的前端新人还是写了好几年业务代码但没时间深挖原理的工程师只要你的页面需要加载 JS、CSS、图片这篇文章就能帮你解答那些平时模模糊糊的问题浏览器到底怎么决定一个资源走缓存还是走网络为什么文件指纹变了之后请求就自动更新了强缓存和协商缓存配合起来为什么能“秒开”又“不锁死”我尽量不堆术语把原理讲得像同事之间聊天一样清楚。1. 资源加载的完整链路一次请求的出发到抵达1.1 从地址栏到服务器DNS、TCP 与 TLS 的三重握手用户在浏览器里输入网址最先发生的不是“下载HTML文件”而是一连串前置的网络准备。首先得把域名解析成服务器真正的 IP 地址这一步叫 DNS 解析。浏览器会依次查内存缓存、系统 hosts 文件、本地 DNS 缓存实在不行才去问上级 DNS 服务器。整个过程看起来毫不起眼但多数情况下你打开一个网页的总耗时里DNS 解析能占到 20% 到 50%尤其在国内跨运营商访问的场景中尤为明显。拿到 IP 之后浏览器要和服务器建立 TCP 连接。经典的 TCP 三次握手大家面试都背过客户端先发 SYN服务器回 SYNACK客户端再回 ACK。但真正写代码的人容易忽略一点——TCP 连接是有成本的而且成本不小。三次握手在公网环境下大约要消耗一次 RTT往返时间如果网站用了 HTTPS还得加上 TLS 握手这一来一回又是 1 到 2 次 RTT。计算下来一个全新的 HTTPS 请求光是建立连接就可能耗时 100 到 300 毫秒。这也是为什么 HTTP/2 的多路复用和连接复用机制这么重要——同一个域名复用一条长连接后续资源请求省下的时间非常可观。1.2 浏览器并发连接数与关键渲染路径的阻塞连接建立之后浏览器开始请求 HTML 文档拿到并解析页面。注意HTML 解析到script标签时默认的行为是“立即下载并执行”这个阶段会阻塞后面 HTML 的解析。如果脚本放在head里且没有加任何标记你会看到页面白屏时间明显变长。解决办法就是给脚本加defer或async属性两者的区别在于defer是“下载完等 HTML 解析完再执行”而async是“下载完立刻执行谁先到谁先跑完全不等人”。CSS 的加载同样有阻塞机制。浏览器在构建 CSSOM 时如果遇到样式表还没有加载完它不会急着渲染页面。这样设计的原因很好理解如果页面先渲染出一版没有样式的裸 HTML然后突然再带样式重绘视觉闪败非常明显。浏览器宁愿等。所以render-blocking CSS这个概念不是瞎说的——你要优化首屏就得想办法让关键的 CSS 内联非关键的 CSS 用异步方式加载。浏览器对同一域名的并发连接数也有限制。HTTP/1.1 时代Chrome 对单个域名最多开 6 条 TCP 连接其他请求都得排队。HTTP/2 上线之后多路复用让所有请求跑在一条连接里逻辑上的并发度大幅提升。但实际实践中HTTP/2 并不是没有瓶颈——如果某个资源特别慢这条唯一的连接也可能会被拖累因此前端打包时的文件数量仍然要控制不因为有了 HTTP/2 就无所顾忌地拆成一堆小文件。1.3 预加载与预连接提前告诉浏览器下一步如果你把资源加载的时序图拉出来看会发现很多网络空闲时间是“浪费”的。比如页面 HTML 都解析完了但某个 JS 文件还要等到几百毫秒后才被 CSS 里引用的图片阻塞顶到。为了填这些空档浏览器提供了预加载系列能力。preload当前页面立刻需要的资源需要提前下载比如首屏要用的字体文件、关键图片。prefetch下一页或稍后可能用到的资源在浏览器空闲的时候悄悄拉取。preconnect提前完成 DNS 解析 TCP 连接 TLS 握手等真正请求时省去连接时间。dns-prefetch提前解析域名比 preconnect 更轻只需要知道 IP 就行。具体怎么用比如你的首页有一个字体文件普通加载模式下浏览器要等解析到 CSS 里font-face才会去请求字体。而用link relpreload hreffont.woff2 asfont typefont/woff2 crossorigin就可以提前把字体拉回来等 CSS 真正用到的时候直接就能渲染。这个技巧对首屏大标题、LOGO 这类文字渲染非常有效。这里提一个很重要的实践心得prefect只适合你“有把握”的后继资源不能滥用。我见过有人把整个站点的路由 chunk 全部 prefetch结果用户只看一个落地页就下载了全站七八个 MB 的 JS白费带宽还拖慢首屏。2. 缓存机制原理拆解强缓存与协商缓存的相爱相杀2.1 强缓存浏览器说了算服务器不知道缓存是 Web 性能的隐形加速器。浏览器拿到一个资源之后不是马上决定它能不能用而是先看“这个资源能缓存多久”“是否过期”。这套规则主要由响应头里的Cache-Control和Expires控制。Cache-Control: max-age31536000的组合大家肯定见过意思是这个资源自下载后一年内有效中间再请求就直接从本地拿连网络请求都不发。这就是强缓存。强缓存命中后的状态码表现非常直观Chrome 开发者工具里会显示200 (from disk cache)或200 (from memory cache)Network 面板里那个请求根本没有完整走一圈网络耗时基本都是 0 到几毫秒。那from disk cache和from memory cache有什么区别memory cache 缓存在内存里读取速度极快但生命周期短标签页关闭就没了。disk cache 缓存在磁盘上跨会话、跨重启都能存活读取速度相对内存略慢但仍是本地 I/O远快于走网络。浏览器具体存到哪一层是根据资源大小和当前内存压力动态决定的开发者一般不用管。注意Cache-Control还有几个名字容易混淆的字段。no-cache听上去像“不缓存”但它的真实含义是“可以缓存但每次用之前必须回服务器验证一下”。no-store才是真正意义的完全不存。还有immutable它表示“这个资源在 max-age 期间内绝对不会变化”浏览器在有效期内连验证请求都省了这个组合通常留给带 hash 文件名的静态资源。2.2 协商缓存每次请求都问一次服务器当强缓存过期时浏览器不会直接放弃缓存它会拿着缓存的资源去问服务器“这个东西你改过没有没改我就不用重新下载了。”这一问一答就是协商缓存。协商缓存服务端主要靠两种响应头来判断Last-Modified/If-Modified-Since按最后修改时间对比秒级精度简单但缺陷明显——文件内容没改但更新时间变了就会误判为需要重新下载或者更新发生在同一秒内服务端可能忽略了。ETag/If-None-Match按文件内容或版本标识对比可以做到内容不变就绝对不重复下是目前更推荐的方案。协商缓存命中的状态码是304 Not Modified。响应体基本是空的但网络请求确实发出去了所以比强缓存慢但比重新下载整个文件快得多。一堆人可能分不清楚强缓存是不上网协商缓存是上网但只带“头”不带“身子”。这俩的级别是强缓存优先只有强缓存失效了才进入协商缓存。2.3 启发式缓存没有缓存头时的“隐形规则”有一种情况特别容易被忽略就是服务器响应里没有Cache-Control也没有Expires时浏览器会偷偷启用启发式缓存。它根据响应头里的Last-Modified估算一个缓存时间大概是“最后一次修改时间到当前时间差值”的 10% 作为一个粗略的缓存寿命。比如一个文件 10 天前更新过且没给任何缓存策略浏览器可能会在接下来 1 天里默认使用本地缓存而不发请求。这个机制本意是好心但在咱们实际开发调试时极其容易踩坑你在开发环境随便改了一个接口忘了加Cache-Control: no-store浏览器可能默认给你缓存好几分钟代码改了页面跟不上几乎必中招。所以我会在本地 dev server 的响应头上统一注入Cache-Control: no-store避免开发时排查问题被缓存误导。2.4 缓存位置再补充一层Service Worker 之上的自定义缓存HTTP 缓存之外Service Worker 提供了一整套可以完全由开发者掌控的缓存层。你可以把静态资源预先存进 Cache Storage可以拦截所有 fetch 请求并决定是走网络还是走缓存甚至能够在断网环境下让应用实现离线可用。SPA 应用的离线包本质就是用 Service Worker 把 HTML、JS、CSS 预先缓存下来。用户第二次打开时哪怕信号差路由器没网页面照样秒开。个人博客、文档站用这个方案做体验升级特别明显。Service Worker 缓存优先级高于浏览器磁盘缓存因为它在 fetch 事件层面就拦截住了请求根本没等到 HTTP 缓存那一层来决策。3. 加载与缓存的协同优化性能调优的实操组合拳3.1 三级缓存体系的设计HTML、静态资源、接口各管各的实际的性能优化工程里很少有“一药治百病”的策略更常见的是分层治理。把资源分成三类每一类给不同的缓存策略第一类是 HTML 文档。这类资源的特点是更新频繁每次发布都可能变里面引用的静态资源路径通常也会变。所以 HTML 不应该开强缓存但也不能完全不缓。常见的做法是Cache-Control: no-cache配合协商缓存。如果服务端支持 ETag用户每次请求都会验证内容没变就 304变化了就返回新页面。第二类是带指纹的静态资源就是文件名里带上 contenthash 的 JS、CSS、图片等。这类资源永远不会被修改只要内容变了文件名就变了缓存键就变了浏览器自然去请求新的。这类资源完全可以用最强策略Cache-Control: public, max-age31536000, immutable一年之内绝对不需要重新验证。第三类是接口数据。这类资源最复杂因为有的接口可以缓有的不能。新闻列表可以做短时间缓存比如 30 秒到 5 分钟涉及用户登录态、购物车数量、账户余额的接口绝对不能缓存要no-store。我见过有团队为了统一配置把所有接口都设了max-age60结果用户下单后购物车数字显示不更新这种坑就属于缓存策略没有差异化。下面给一个比较通用的建议配置表资源类型响应头配置说明HTML 入口Cache-Control: no-cache每次回源验证配合 ETag 协商带 hash 的静态资源Cache-Control: public, max-age31536000, immutable一年长缓存文件名变我就更新不带 hash 的静态资源Cache-Control: no-cache防止误缓存老版本个性化接口Cache-Control: no-store绝不缓存避免数据错乱公共内容接口Cache-Control: max-age60, stale-while-revalidate300缓存短时间后台再异步刷新stale-while-revalidate是个宝藏字段值得单独说。它允许用户在缓存过期之后、回源刷新完成之前先用旧的缓存响应请求避免白屏等待。也就是页面看起来秒开然而网络层在后台静默更新数据。对于内容不是极其实时、但希望首屏体验流畅的场景这个字段相当适用。3.2 缓存版本号的设计为什么文件名 hash 比时间戳更靠谱处理静态资源版本更新的方式有好几种最基础的是给文件名加版本号比如app.js?v20240201。这种方案确实能让缓存键变化但有个坏处如果你改了内容但忘了更新版本号浏览器会把旧缓存拿出来继续用。还有一种是用打包工具生成 hashapp.8f3a1b2c.js内容一变化 hash 就变文件名也就变了浏览器请求的是一个全新的 URL完全绕开旧缓存。这个方案我强烈推荐。只要构建流程靠谱你绝对不会遇到“改了代码线上没效果”的经典问题。而且配合 immutable 强缓存旧资源可以一直留在用户的磁盘缓存里新资源又是一个新文件不存在覆盖或半新半旧的状态。更新体验干净利落原理上这就是“内容寻址”——文件名是内容的指纹内容变了地址就变。在实际构建配置里Vite、Webpack、Rollup 这些工具都默认支持 contenthash。你只要在打包配置里把输出文件名写成包含 hash 的形式就行。比如 Vite 默认构建就是assets/index-[hash].js不用额外做什么但注意 hash 要选contenthash不要用chunkhash避免同一个文件中只有代码注释变了也触发所有 chunk 失效。3.3 缓存与服务端配合CDN 层的回源差异前端缓存和 CDN 缓存是接力关系。浏览器先问本地缓存没命中就走到 CDN 节点CDN 节点也没缓存才会回到源站。源站返回资源时带上了Cache-ControlCDN 就按这个头缓存一份对外服务。CDN 层和浏览器层的策略最核心的区别在于CDN 通常面向海量用户聚合流量它的缓存命中率影响源站压力浏览器面向单个用户缓存策略直接影响单用户访问速度。如果把Cache-Control: private带上CDN 就不会缓存该资源比如 HTML 私有页面而静态资源一般用publicCDN 才会继续缓存。 配置 CDN 时还要额外关注s-maxage。这个字段是专门给 CDN 这类共享缓存看的优先级高于max-age。比如一个接口你希望浏览器缓存 60 秒但同时希望 CDN 缓存 300 秒就可以同时写Cache-Control: public, max-age60, s-maxage300。3.4 缓存更新的利器Service Worker 与 Cache API 配合有了 HTTP 缓存还不够SPA 应用想实现完全离线、秒开就得靠 Service Worker 加 Cache API 的组合。我自己的实践方案是分层设计。第一层构建后的 HTML 配置为no-cache每次在线都走协商缓存确保用户尽快拿到新版本页面。第二层JS/CSS 等静态资源做永久缓存文件名带 hash。第三层Service Worker 安装时把 HTML 和核心静态资源预缓存到 Cache Storage下次启动时优先从 Cache Storage 读取实现秒开效果。第四层后台再怎么去校验 HTML 是否变化有新版本就把新资源拉进缓存再提示用户刷新或自动刷新。这里要特别注意 Service Worker 的更新策略。如果新的 Service Worker 更新时没有清理旧缓存版本号一变旧资源永远残留在那儿占着用户的磁盘空间不说还可能造成“明明已经更新了页面还是旧版”的诡异问题。一个比较稳妥的做法是把缓存命名与版本号绑定比如my-app-v1、my-app-v2每次更新时删除旧版本的 Cache Storage避免出现僵尸缓存。4. 常见问题与排查技巧实录4.1 为何改了代码线上页面纹丝不动这个问题几乎每个前端都经历过而且绝大多数时候不是代码问题是缓存问题。排查可以按这个顺序走先在 Network 面板看请求的状态码。如果显示200 (from disk cache)或者200 (from memory cache)说明命中强缓存你下载的页面根本是旧的。解决办法很直接确认站点的 HTML 响应头里有没有no-cache有的话还要确认最终用户访问的是不是根路径或者带有正确 host 的 URL避免域名节点缓存叠加。如果显示的是304说明服务端已经收到请求并确认过内容没变那就要回源检查一下源站文件的真实更新情况有可能是 CDN 节点没刷新也可能是代码发的是灰度环境源站文件确实还是旧的。4.2 为什么强缓存无限期但页面内容却正确更新有朋友不理解js 文件max-age31536000那我改代码后用户怎么看到新内容的其实秘密就在文件名带 hash。你发布新版本后比如app.a1b2c3.js变成了app.d4e5f6.jsHTML 里引用的路径也跟着变了。浏览器加载 HTML 时发现新的 JS 路径自然就去下载新文件而旧文件因为一年期缓存还没过期就继续躺在旧用户本地反正也不会再被引用最终被 LRU 算法淘汰掉。这就是为什么“静态资源无限期缓存 HTML 不缓存”是行业标准组合。这里有个细节要提醒如果你们团队的构建工具配置里 hash 没有参与文件名或者 hash 是在某个标签里单独加的那上面这套逻辑就不生效。所以我会经常检查线上 HTML 源码里的资源路径确保后缀确实是 unique hash。4.3 协商缓存请求过多能不能让资源完全不回源项目上线后发现明明静态资源一年内不会变但 Network 面板里还是能看到不少 304 请求。这种情况一般是响应头里没配immutable或者在静态资源上加了no-cache。补上合适的Cache-Control就能让浏览器在有效期内完全不发验证请求。但注意不要把所有资源都设成一年长缓存。比如用户的头像如果你用max-age31536000缓了用户的旧头像用户换了新头像后老资源会一直缓存在所有用户本地那场面就是满屏旧头像。头像、用户资料这类内容no-cache或者短缓存更合理。4.4 缓存的暗坑跨域资源、缓存共享与隐私问题处理缓存时有个安全问题非常容易忽略浏览器对完全公开的目标使用了共享缓存。如果你的某个接口返回了带个性化内容的数据又没有设置Cache-Control: private那么在公共代理/CDN 环境下另一个用户可能命中了前一用户缓存的响应。这种事情在登录态、订单信息接口上千万不能发生。这也解释了我的推荐表格里对个性化接口一律no-store的原因。开发环境下也有一个关于跨域的坑Chrome 对file://协议或某些跨域请求会禁用磁盘缓存导致你在本地测试时明明配置了缓存却每次请求都走网络。模拟真实环境最稳的办法是用本地起 HTTP 服务比如python -m http.server 8000或npx serve而不是直接双击 HTML 文件用file://打开。4.5 排查技巧用右键菜单和 DevTools 绕过缓存做精确验证为了排查缓存问题我通常会在 Network 面板勾选Disable cache。这个选项只在 DevTools 开着的时候生效用来验证“关闭所有缓存后页面是否正常”特别好用。但它不是万能的——它只禁用了浏览器缓存不一定会清掉 Service Worker 缓存也不影响 CDN 缓存所以排查时务必要分清层次。如果需要精准绕过 Service Worker可以在 Application 面板的 Service Workers 里勾选Bypass for network或者在 Network 面板右键请求选择Clear browser cache / Clear site data。我的习惯是三步走先 Disable cache 确认代码正确再清掉 Service Worker 确认离线包不阻碍最后在本地环境模拟生产请求头验证 CDN 是否回源正确这样一层一层排除基本不会死锁。5. 踩坑总结那些文档里写不出来的体验真正深入资源加载与缓存机制之后你会发现这些知识不是孤立的“配置项背诵”而是环环相扣的系统工程。你优化了域名并发限制就得考虑 HTTP/2 下的连接成本你配置了强缓存就必须配合 contenthash 才能优雅更新你用了 Service Worker就逃不开版本管理和脏缓存清理的问题。我个人玩这套东西踩过最深的坑是在云静态部署场景下给 HTML 配置了max-age3600把全站首页缓存了 1 小时。结果每次发布后自己验证永远要手动清缓存而用户那边全部看到旧版。后来学习到 HTML 永远用no-cache之后问题自然消失这个案例也成了我每次讲性能优化必然要提到的反面教材。回头看资源加载是“快和慢”的博弈缓存机制则是“新和旧”的权衡。把这两条线索理清楚很多表面上奇奇怪怪的线上问题答案就在 Headers 里面的几行配置上。做个务实的前端不要背概念直接打开 DevTools去 Network 面板里反复对比强缓存命中、304 协商、多路复用这几个状态你会的比背十遍书都多。