前端缓存这玩意儿，在圈子里一直是“人人都知道很重要，但真没几个人认真做”的状态。我身边不少同事，一聊性能优化就是上CDN、压缩图片、加懒加载，问起缓存策略，得到的回答往往是“哦，那不就是设置个Cache-Control吗”。但在我看来，前端缓存恰恰是整个性能优化链条里被低估得最厉害的一环——它不需要你砸钱买昂贵的服务器资源，不需要重构项目架构，只要配置到位、思路清晰，就能在第一次访问体验基本不变的前提下，把二次访问的加载时间砍掉一大半。这篇文章，我想结合自己这些年从前端开发到性能优化专项的经验，把前端缓存这套体系掰开揉碎了讲清楚，包括缓存的分类、底层原理、实战配置，以及那些网上不太会明说的避坑心得。适合刚接触性能优化的前端新人，也适合已经在做优化但总觉得差点意思的开发者。
1. 为什么说前端缓存是被低估的性能优化技巧
1.1 大家都在聊优化，却总是绕开缓存
性能优化的话题从来不缺热度，随便刷一刷技术社区，能看到的名目多得吓人：Julia那边的性能优化与内存管理，Oracle SQL的执行计划调优，手游里那套DrawCall和内存占用优化，移动端的启动速度和卡顿治理——各有各的深水区。但回到我们前端领域，大家聊得最多的还是打包体积、图片压缩、代码分割这一类看得见摸得着的东西。缓存这个东西，入口很浅、貌似很好懂，但真往深处走，机制盘根错节，很多人试了两次觉得“没啥效果”就放弃了。
为什么会出现这种情况？我觉得主要是两个原因。第一个原因是缓存的收益是非线性的：它不像压缩一张图片那样，改完立竿见影、文件大小数字直接变小。缓存的效果体现在“第二次打开变快了”“弱网环境下依然流畅”，这个感知是间接的、滞后的。第二个原因是缓存策略在业务中的表现太容易“出问题”，比如改完CSS用户死活不更新，于是很多人就干脆粗暴地把缓存全停了。甭管是大厂还是小团队，我都见过这种极端做法——缓存全禁用，每次请求都回源，看起来“没有缓存导致的文件不更新问题”了，实际上是把性能和成本双双拖垮了。
1.2 看一张请求图，你就知道缓存的份量
我之前优化过一个后台管理系统，首屏静态资源加起来大概有1.2MB，没做任何缓存策略的时候，每次刷新页面，这些资源全部重新下载，无谓的流量浪费和等待时间非常明显。后来我加上了一套常规的HTTP缓存配置，并把重复访问的命中率提升到90%以上，实际效果是：二次访问时静态资源请求的网络耗时近乎归零，整体页面加载从2.8秒降到了0.7秒左右。
这里面有一个很直观的逻辑：性能优化解决的是“怎么更快地把东西拿到”，缓存解决的是“能不能干脆不拿”。如果说CDN是把资源搬到离用户更近的地方，那缓存就是把资源直接塞进用户兜里，连路都不用跑。跟压缩资源、合并请求这些“减负”型优化手段不同，缓存是唯一一种能够直接把网络请求成本归零的思路。单凭这一点，它就值得被放在性能优化方案里的第一优先级。
1.3 谁能从中受益
不论你是写业务页面的应用开发者，还是维护组件库、工具库的基建同学，都能从缓存体系里拿到实打实的好处。应用开发者最常见的使用场景是静态资源的长期缓存和接口数据的本地复用；基建方向的同学则可以做更底层的事情，比如把公共依赖包单独抽出来，配合CDN加上版本号做永久强缓存，从而让多个业务项目共享同一份缓存文件。这种收益在大型中后台项目里尤为明显——我见过公共依赖的缓存命中率做到95%以上，整个系统每天的静态资源回源流量降低到了原来的几十分之一。
所以这篇文章的定位，就是帮你把缓存这个工具箱里的每件工具都认识清楚，然后告诉你什么场景该用哪一件，以及怎么避开那些大家常踩的坑。
2. 前端缓存体系整体设计：你需要掌握的四层缓存
2.1 把缓存当成一个体系，而不是单一开关
很多开发者对缓存的认知停留在“设置一个Cache-Control头”这一层，这其实是一个很大的误区。前端缓存的完整体系远不止HTTP缓存这一层。我从底向上梳理，大致可以分成四个层次：浏览器内存缓存、HTTP缓存（强缓存与协商缓存）、本地数据存储（Storage家族）以及Service Worker自定义缓存。每一层能解决的问题不同，策略也不一样，完全不能一概而论。
打个比方，这四层缓存就像是一个家庭里的四个冰箱：内存缓存是那种放在厨房台面上的小冷藏盒，容量小但拿取最快，适合放马上要用的东西；HTTP缓存是客厅的大冰箱，容量大、存取规整，是绝大多数食物（静态资源）的存放主力；本地数据存储是地下室里的仓库，不常开但能存大量东西，适合放需要“过夜”的数据；Service Worker则是你的私人管家，可以自己制定规则，决定什么东西放哪里、过期了怎么处理。
很多项目的问题恰恰出在这里：只用大冰箱，其他空间全空着，导致大量本来可以更高效处理的数据走了不合适的路。
2.2 四层缓存的职责划分与协作逻辑
这四层缓存不是独立工作的，它们之间有明确的协作顺序和回退关系。
当一个页面发起一个静态资源请求时，浏览器会先去内存缓存里找——注意，内存缓存的特点是“只要标签页还开着，资源就可能在里面”，它的判断依据很简单，看这个资源是否已经被当前页面加载过，而且没有强制刷新页面。如果在内存缓存中找到了，那请求根本不会走到网络栈；找不到，它才会去看HTTP缓存，也就是我们通常说的磁盘缓存。磁盘缓存命中了，那网络层就省了；没命中，请求才真正发到服务器。
Service Worker比较特殊，它是独立于页面运行的一层代理，可以在请求发出去之前拦截它，决定是直接返回缓存、回源更新还是走网络。Service Worker的缓存命中后，同样不需要走到网络层——而且它的兼容性很好，除了基础的支持要求HTTPS环境之外，在现代浏览器上已经非常成熟了。
至于本地数据存储（localStorage、sessionStorage和IndexedDB），它们一般不负责保存静态资源文件，而是专注在业务数据层面。比如用户信息、字典数据、上次浏览记录这类内容，没必要每次都通过接口拉取，完全可以存下来供后续会话使用。我之前做过一个报表类的项目，把影响最大的几个字典接口做了本地缓存，整个项目启动时需要等待的接口数从9个降到了2个，体感速度提升是肉眼可见的。
2.3 核心原则：分层管理，各司其职
搞定前端缓存，最核心的一条原则就是“分层管理，各司其职”，简单说就是为每一类资源、每一种数据场景挑选最合适的那一层缓存。静态资源尽量交给HTTP缓存和Service Worker，业务数据考虑Storage家族，而像页面当前状态的临时数据则可以利用内存缓存。
这一章先把这个大图景放在你脑子里，接下来的内容，我会把其中最关键的三层——HTTP缓存、Service Worker缓存、本地数据存储——分别展开，把操作细节和参数配置讲透。
3. HTTP缓存核心细节：强缓存与协商缓存的实战选择
3.1 强缓存：Cache-Control与Expires的正确打开方式
HTTP缓存是整个缓存体系的地基，也是最容易被用错的部分。我见过不少项目中，直接就写一句Cache-Control: max-age=3600就完事了。这个用法本身没有错，但它完全没体现出HTTP缓存的精细控制能力。
先看强缓存。强缓存的核心语义就是“在缓存有效期内，浏览器压根不会发出任何请求，直接使用本地副本”。实现强缓存最严谨的方式是用Cache-Control响应头，它支持的指令非常多。比如max-age表示相对当前时间的有效秒数；public和private则告诉代理服务器和浏览器这个响应能不能被各级缓存保存；immutable则是一个对刷新操作很友好的指令，它能告诉浏览器这个文件在过期时间内是绝不可能变的，哪怕用户手动刷新页面也不需要重新验证。
在我维护的项目里，资源类型不同，Cache-Control的配置也完全不同。版本化命名的静态资源（也就是文件名里带了hash指纹的），我会配置Cache-Control: public, max-age=31536000, immutable，说白了就是一年有效期且不用重新验证。对于HTML文档本身，则配置成no-cache——注意，no-cache听起来像是不缓存，其实它的意思是“缓存但是每次使用前必须回源验证”，这对确保页面内容及时更新非常关键。
老版本HTTP协议还支持Expires响应头，它是一个绝对的过期时间。但由于它依赖客户端本地时间，一旦用户改了系统时间就会闹出缓存不更新的问题，现在基本只作为向后兼容的兜底存在。新项目我优先建议直接用Cache-Control，不用再纠结。
3.2 协商缓存：ETag与Last-Modified的工作机制
聊完了强缓存，再看协商缓存。协商缓存和强缓存最大的区别是：浏览器每次都真的会发请求到服务器，但如果服务器判断资源没有变化，会返回一个304 Not Modified，响应体为空，这时候浏览器继续用本地缓存副本。这样做虽然没有完全省掉网络请求，但省掉了资源主体内容的传输，对于体积较大的文件来说仍然是巨大的性能提升。
协商缓存的核心机制是Last-Modified（文件最后修改时间）和ETag（实体标签，一串根据文件内容计算出的哈希值）。前端发起请求时，会把上次响应里带的Last-Modified或ETag通过If-Modified-Since或If-None-Match请求头回传给服务器，服务器拿这个标识和当前文件做对比，如果没变化就返回304 Not Modified。
这里我要特别强调一个经验：优先使用ETag而不是Last-Modified。原因很实际，Last-Modified的最小颗粒度是秒，如果文件在同一个秒级时间窗内发生了内容变化，服务器可能无法识别出差异，从而返回200和完整内容，白白浪费了带宽。而ETag是内容相关的，文件有一点变化，ETag就一定会变，对比精确度远高于时间戳。不过ETag也有计算成本，如果文件非常巨大而且请求量极高，服务器端的压力也值得关注。稳妥的做法是两者同时开启，让服务器优先用ETag做判断。
3.3 参数选择背后的服务器配置实践
理论说清楚后，我们看一个具体的Nginx配置实战。我拿一份简化过的配置来说明这个原理：
# 版本化静态资源：一年期强缓存，无需回源验证 location /static/ { alias /data/www/static/; expires 1y; add_header Cache-Control "public, immutable"; etag on; } # HTML页面：每次都必须回源验证 location / { root /data/www/html; index index.html; add_header Cache-Control "no-cache"; etag on; } # 动态接口：完全不缓存，确保实时性 location /api/ { proxy_pass http://backend_server; add_header Cache-Control "no-store"; }这套配置的核心逻辑是：带hash指纹的静态文件（/static/下的文件）依靠文件名变化来做版本更新，所以内容一旦发布就永久有效，直接放进强缓存；HTML作为入口文件，必须每次更新后让浏览器能拿到最新内容，所以使用no-cache策略做协商验证；而接口数据默认不缓存，保证业务实时性。
要注意的是，Nginx里的expires 1y;指令会自动生成Expires头，跟Cache-Control: max-age=31536000一起下发，两者共存时浏览器优先采纳Cache-Control，所以兼容性这块不用太担心。
3.4 静态资源版本化与缓存失效策略
要在HTTP缓存上做出最佳实践，有个前置条件必须做好：文件版本化。简单说就是，每次文件内容变了，文件名也要跟着变，通常是在文件名中拼接一段内容hash。构建工具如Webpack、Vite都支持在输出文件名里自动注入hash。只有做到这一点，你才能理直气壮地在静态资源上设置一年甚至更长的缓存时间。
为什么？因为你发布的不是“同一个文件”，而是“名为v1的文件”和“名为v2的文件”。旧文件名带着旧内容一起被浏览器永久缓存了，新文件名自然会产生新的缓存条目，从源头杜绝了“用户拿到了旧版本却以为是最新版”的尴尬。如果某个项目没有做版本化，同时又粗暴地设置了永久缓存，那用户更新到最新版本基本只能靠在地址栏敲回车外加硬刷新，体验会非常糟糕。
4. Service Worker缓存实战：把缓存主动权拿回自己手里
4.1 Service Worker能为你做什么
如果说HTTP缓存只能依赖服务器响应头被动生效，那Service Worker就把主动权交到了前端开发者手上。Service Worker本质是一个独立于页面运行的JavaScript脚本，它可以拦截页面发出的所有网络请求，然后根据自己的内部逻辑来决定返回策略。
在我参与过的移动端H5项目中，Service Worker带来的提升是最显著的。由于移动网络环境波动大，弱网下的每次请求都能感受到明显的延迟。我写了一个预缓存版本的核心CSS、JS和图片，再用运行时缓存策略去处理其余资源，结果就是用户在弱网状态下打开页面，相关的静态资源几乎全部从Service Worker缓存里读取，加载体感好了非常多。
Service Worker的另一个隐藏价值是“缓存优先”模式极其适合某些特定场景。比如离线页面：用户断网的时候，走网络的请求全部失败，但Service Worker可以拦截请求并直接返回预先缓存的离线兜底页面，让用户至少能看到一个体面的错误提示或离线内容，而不是赤裸裸的浏览器错误页。这个体验，对于页面可靠性要求高的产品（比如PWA、移动端工具应用）来说非常加分。
4.2 缓存策略选择：缓存优先还是网络优先
Service Worker的拦截逻辑可以分为几种典型策略，每种策略的适用场景完全不同。
- Cache First（缓存优先）：只要本地有缓存就直接返回，完全不走网络，同时后台悄悄更新缓存。适合版本化静态资源，比如CSS、JS、图片、字体。
- Network First（网络优先）：先尝试从网络请求，拿到新数据就缓存起来；如果网络挂了（超时或失败），才回退到缓存。适合页面HTML、接口数据这一类“尽可能要最新，但断网时也有兜底”的内容。
- Stale While Revalidate（过期缓存复用并后台更新）：返回缓存内容，同时发起后台请求来更新缓存，下次访问就用新的。适合那些对实时性要求不高、但也不能太旧的内容。
- Network Only（仅网络）：不读缓存、不写缓存。适合涉及用户隐私或敏感数据的接口，比如支付、登录等场景，绝不碰缓存。
我比较推荐的做法是：静态资源用Cache First，HTML入口和常规业务接口用Network First，展示型内容或低频变化数据用Stale While Revalidate。这样既有速度，又不至于让数据新鲜度崩盘。
4.3 核心代码实现：注册与拦截
这里我拿一个简化版的Service Worker注册和缓存逻辑来展示真实写法。页面端的注册很简单，在入口文件里追加一段：
// 主线程：注册Service Worker if ('serviceWorker' in navigator) { window.addEventListener('load', () => { navigator.serviceWorker.register('/sw.js').then(registration => { console.log('Service Worker registered: ', registration.scope); }).catch(error => { console.error('Service Worker registration failed: ', error); }); }); }如果你用的是构建工具，比如Vite，可以直接使用vite-plugin-pwa这类插件，它会把Service Worker的生成和注册流程都封装好，配置起来很方便。但如果项目比较小，或者你想完全掌控它的行为，手写一个sw.js往往更清晰。
然后在sw.js中实现缓存拦截逻辑：
// sw.js const CACHE_VERSION = 'v1'; const STATIC_CACHE = `static-${CACHE_VERSION}`; const PAGE_CACHE = `page-${CACHE_VERSION}`; // 定义需要预缓存的核心资源 const PRE_CACHE_URLS = [ '/', '/index.html', '/static/js/main.js', '/static/css/main.css', '/static/img/logo.png' ]; // 安装阶段：预缓存核心资源 self.addEventListener('install', event => { event.waitUntil( caches.open(STATIC_CACHE).then(cache => { return cache.addAll(PRE_CACHE_URLS); }).then(() => self.skipWaiting()) ); }); // 激活阶段：清理旧版本缓存，避免缓存空间膨胀 self.addEventListener('activate', event => { event.waitUntil( caches.keys().then(cacheNames => { return Promise.all( cacheNames.filter(cacheName => { return cacheName.startsWith('static-') && cacheName !== STATIC_CACHE; }).map(cacheName => caches.delete(cacheName)) ); }).then(() => self.clients.claim()) ); }); // 请求拦截阶段：按策略分发处理 self.addEventListener('fetch', event => { const requestUrl = new URL(event.request.url); // 同源静态资源：试试缓存优先 if (event.request.destination === 'style' || event.request.destination === 'script' || event.request.destination === 'image') { event.respondWith( caches.match(event.request).then(cachedResponse => { if (cachedResponse) { return cachedResponse; } return fetch(event.request).then(networkResponse => { const clone = networkResponse.clone(); caches.open(STATIC_CACHE).then(cache => cache.put(event.request, clone)); return networkResponse; }); }) ); return; } // 页面导航请求：网络优先，失败时回退缓存 if (event.request.mode === 'navigate') { event.respondWith( fetch(event.request).then(networkResponse => { const clone = networkResponse.clone(); caches.open(PAGE_CACHE).then(cache => cache.put(event.request, clone)); return networkResponse; }).catch(() => { return caches.match(event.request).then(cachedPage => { return cachedPage || caches.match('/index.html'); }); }) ); return; } });这段逻辑并不复杂，核心就是在fetch事件里对不同的请求类型做不同的处理。静态资源走Cache First，页面导航走Network First，这样在离线时也能打开页面。
4.4 Service Worker的坑与规避方案
Service Worker用起来很香，坑也不少，很多还是注册之后才会显现出来的。我踩过比较深的一个坑是：Service Worker注册成功后在开发者工具里看不到任何输出，各种调试信息打了也看不见。这个问题的原因是Service Worker与页面的调试通道是独立的，你在主线程控制台里拿不到它的console日志，必须到“Application”面板里的“Service Workers”子面板单独打开它的调试窗口才行。
更大的坑来自更新机制。Service Worker脚本本身如果内容更新了，浏览器会默认按字节对比重新激活，但这个过程不是即时的——新版脚本会进入waiting状态，旧版本还在运行，直到用户关闭页签后才会切换。解决方法是安装阶段调用self.skipWaiting()，激活后调用self.clients.claim()，让新版本立即接管页面。上面那份代码已经包含了这两个关键调用。
另外必须强调的是：Service Worker只能在HTTPS环境下运行。本地开发时localhost属于可信来源，可以正常调试，但一旦部署到线上环境，没有HTTPS的话Service Worker根本不会生效。这个限制是硬性的，如果你还在用明文HTTP，做这个方案之前得先把证书装上。
5. 本地数据缓存与存储选型：别让业务数据反复请求
5.1 为什么接口数据也需要缓存
很多人一提缓存就是静态资源，这其实浪费了一大片优化空间。接口数据的重复请求，在业务系统里是非常常见且可耻的浪费。举个例子：一个后台管理页面，登录后需要拉取用户信息、权限菜单、配置字典、通知列表等等，这些数据在一天之内几乎不会变化，但用户每刷新一次页面就要重新请求一遍。
我之前接手过一个公司内部的运营平台，它的数据字典接口（比如状态枚举、类型映射）在启动时会被十几个页面同时调用。排查后发现，仅仅是这些字典接口，就占了当天总请求量的30%以上。后来我在请求层加了一道缓存：这些数据首次请求后写入localStorage并记录时间戳，有效期内直接用本地数据，只有过期后才重新请求。结果非常直观——整个平台的冷启动请求数减少了超过四成，白屏时间缩短了接近一半。
这里我想说，接口缓存并不是“为了缓存而缓存”，它的本质是把那些时效性低、重复率高的数据，从网络层面剥离出来，让网络资源专注服务于真正需要高实时性的请求。
5.2 localStorage、sessionStorage与IndexedDB的适用边界
数据缓存不是随便找个Storage塞进去就行，选型很关键。我在很多项目里都见过把大JSON往localStorage里硬塞的做法，塞到浏览器给出一句“五大爷你是不是想占满我的存储空间”的报错才停手。localStorage的容量限制通常是5MB左右，存一些小配置、用户偏好是够用的，但它同步读取、不能存复杂对象，还要注意它只能存字符串，存对象前必须JSON.stringify。
sessionStorage的生命周期绑定标签页，页面关了就没了，适合保存那种“本次会话内短暂需要”的数据，比如页面间的搜索条件传递、草稿内容，它的特点是不污染全局，用完即走。
如果需要存储较大数据量或者需要查询能力，就得请出IndexedDB了。IndexedDB的容量通常能达到几百MB甚至更多，可以存储结构化数据、二进制文件、Blob，还带索引查询能力，处理复杂数据的本地化非常强。它的API偏底层，回调模式写起来比较费劲，但现在用idb这类Promise封装库之后，体验已经好很多，值得一试。
合理的选型建议是：简单配置和小数据量用localStorage；会话级别的临时数据用sessionStorage；结构化、大体积的数据查询场景交给IndexedDB。
5.3 代码示例：为接口数据加上“保质期”
下面是我在一个项目中实际采用的接口缓存封装，核心思想就是给缓存数据带上时间戳，过期自动失效。
// 对外暴露的缓存读取接口 export function getCache(key) { try { const data = localStorage.getItem(key); if (!data) return null; const record = JSON.parse(data); const now = Date.now(); // 判断过期时间 if (record.expireAt && now > record.expireAt) { localStorage.removeItem(key); return null; } return record.value; } catch (e) { return null; } } // 对外暴露的缓存写入接口 export function setCache(key, value, ttl) { const record = { value, expireAt: Date.now() + ttl }; localStorage.setItem(key, JSON.stringify(record)); } // 实际使用示例：字典数据，缓存5分钟 const dictKey = 'cache:system_dict'; let dict = getCache(dictKey); if (!dict) { dict = await fetchSystemDict(); // 模拟接口请求 setCache(dictKey, dict, 5 * 60 * 1000); }这段代码核心就干了两件事：写缓存时把过期时间算好存进去，读缓存时先判断过期没，过期就当没缓存过。很好的平衡了实时性与性能。唯一需要注意的是，一旦缓存方案失误，用户可能会看到过期数据，所以关键业务数据（比如订单状态、支付结果）绝对不要走这种缓存方案。
5.4 数据一致性：缓存与更新的博弈
接口缓存最大的痛点都集中在数据一致性上。用户的某个操作改了数据，如果缓存还在有效期内，展示出来的还是旧值，就会造成明显的“数据不对”的错觉。
我的经验是给接口按“数据变更频率”和“错误容忍度”分等级：允许一定程度延迟的数据（字典、分类、用户偏好）可以放心缓存；敏感度高、变更频繁的数据（金额、库存、状态）一律不缓存，需要实时请求。另一个技巧是：当用户在页面内执行了写操作（比如提交表单、删除数据）后，立刻主动失效相关联的缓存，下次读取时强制走网络获取最新数据，这样就能大幅降低缓存导致的数据滞后问题。
6. 常见问题与排查技巧实录：缓存踩坑与解决之道
6.1 开发环境里改完代码，浏览器死活不更新
这是每个前端都经历过的地狱时刻：代码明明改好了，刷新页面还是老样子，F12开着Network面板，所有静态文件都是灰色，显示from disk cache。
这个问题的根源十有八九是强缓存过长的max-age，或者本地服务器配置了immutable。解决思路分两层：一是开发环境下要完全禁用静态资源缓存。Webpack的devServer里通过devServer.headers设置Cache-Control: no-store，Vite的话可以直接配server.headers属性。
如果开发环境已经配置正确，还是遇到缓存问题，那就多半是浏览器自身的Service Worker在作祟。尤其是你开发过PWA或者注册过Service Worker之后，即使删掉了代码，浏览器依然会保留之前注册的Service Worker。解决办法是在开发者工具的Application面板里找到Service Workers列表，点“Unregister”，顺手把底下的“Update on reload”勾上，保证每次刷新都拿到最新代码。如果这些都不管用，干脆Ctrl+Shift+R硬刷新，一步到位。
6.2 发布上线后用户还是访问到旧版本
线上环境比开发环境更麻烦，因为用户分布分散，刷新行为各异。我们发布新版本后经常遇到一种戏剧性场景：自己这边看着一切正常，但用户微信群里的截图显示的还是旧版界面，于是客服电话被打爆。
这类问题的核心在于HTML入口文件被强缓存了。假如你的Nginx配置把index.html也配了max-age=604800，那用户在一周之内都会执着地使用旧版本的HTML，怎么刷新都没用，因为浏览器根本不会发请求出去验证。正确做法是像我在第3章里讲的那样：HTML入口永远用Cache-Control: no-cache，每次使用前必须回源验证；只有带hash指纹的静态资源才允许坐拥超长缓存。
另外，如果在HTML中引用的静态资源路径不是每次都带上新hash，也难以避免这个问题。构建工具要确保产物文件名包含内容hash，并且HTML中引用路径每次随hash变化，旧文件名自然会被新的文件替换掉。
6.3 缓存命中率低：命中率衡量与优化方向
有时候配置都做好了，但一看Network面板，很多请求还是200而不是200 (from disk cache)或304。这说明缓存命中率偏低，资源没有物尽其用。
从我的排查路径来看，缓存命中率低通常来自三个方向：第一，响应头里没带缓存字段或字段太短，导致浏览器快速过期；第二，资源本身不带hash版文件名，导致同一个文件名永远指向同一个缓存条目，每次内容更新后都没有办法生成新的缓存键；第三，缓存是配了，但CDN节点或者说代理服务器层层加码，把缓存头覆盖了，导致源站的配置没有真正生效。
针对前两种情况，修正方式很明确：静态资源改成长时间强缓存+hash文件名，动态接口按需做短时缓存。第三种情况要抓典型：如果走了CDN，一定要在CDN控制台里检查缓存头是否被剥离或者重写，很多CDN默认会忽略源站的缓存头然后使用自己的一套规则，那你在源站配半天也白配。验证方法是curl请求一下资源的完整响应头，看看Cache-Control到底是怎么写的。
6.4 调试工具与指标：怎么知道缓存到底生效没有
最后给你一套非常实用的验证思路。打开Chrome开发者工具，切到Network面板，点击一个静态资源，看Headers中的Cache-Control和Expires，再切换到Timing标签页，看是否有from disk cache或者from memory cache的标注。没有标注的话，就说明这次请求走了网络，没吃到缓存红利。
想要系统性地观察命中情况，可以在DevTools里开启“Disable cache”反着测：勾选后刷新页面，所有请求都应回源；取消勾选再刷新一次，观察有多少请求变成了from disk cache或304。两者一对比，你的缓存配置到底有没有生效就非常直观了。
如果嫌手动看不过瘾，还可以在总线上埋点：Service Worker的缓存命中情况和Storage缓存命中情况都能通过代码统计上报，拿到真实用户在具体网络环境下的缓存命中率，这个数据比任何“我觉得已经生效了”都更有说服力。
7. 一套可落地的缓存方案模板与经验总结
讲完各个层面的原理与实现，我直接把一套我多次在真实项目中使用过的缓存方案模板送给你，你可以在这个基础上按业务场景微调直接使用。
静态资源（JS、CSS、图片、字体）——使用带hash的文件名，配置一年期强缓存，附带immutable标识。HTML入口——配置no-cache，强制每次回源验证。常规业务接口——在请求层做本地缓存，时效性按业务需求定（10分钟到24小时都行）；敏感数据接口——不缓存，必须实时请求；用户离线可用性要求高的场景——引入Service Worker，核心静态资源预缓存，HTML页面走Network First兜底。
这套模板的核心价值在于，把不同内容的缓存策略放在了一起：永久缓存放静态资源、协商验证放HTML、时间戳控制放业务数据、Service Worker做离线兜底。四个维度互相配合，整个项目的加载性能、网络成本和容错能力都能得到显著改善。
在具体落地时，最后分享几个我在实操中反复验证过的心得：
第一，给缓存建立版本号管理。无论你用的是Cache-Control、Storage还是Service Worker，最好能让“版本号上升”变成一个自动化动作，从源头规避旧缓存的遗留问题。第二，默认禁用缓存容易，但不要把它当成解决方案。所有接口、页面、资源都实时请求，当然不会出现“缓存未更新”的问题，但同时你会付出性能和成本的双重代价，这在规模化项目里是走不通的。第三，缓存配置优化完之后，一定要记录优化前后的性能数据对比。只有拿出“静态资源请求数下降X%”“首屏时间缩短Y秒”这样的真实指标，你才能说服团队其他成员认可这项工作的价值。
缓存不是调完一个参数就万事大吉的技术，它是一整套需要持续观察、持续校准的体系。希望这一路拆解下来，能帮你把缓存从“听说过”、“大概懂”变成“用得好”、“能说服别人”的硬技能。
