前端缓存策略详解：从HTTP缓存到CDN与Service Worker

你是不是也遇到过这种场景：同一个页面，在自己的电脑上打开飞快，换台机器或者让别人访问，慢得像在加载整个银河系。或者更气人的，明明刚改完样式和脚本，部署上线后用户那边还是老版本，怎么刷新都没用，最后只能让用户强制清缓存。每次遇到这种问题，大家第一反应就是“缓存搞得鬼”，但真要让你系统地说说前端缓存策略到底是什么、怎么搭一套稳定又高效的缓存方案，很多人又讲不清楚了。

前端缓存策略，说白了就是一套“让网站飞起来”的组合拳。它解决的不仅仅是首屏加载速度，还包括带宽成本、服务器压力、用户体验的一致性，甚至是发布上线时的平滑度。这篇文章我就以一线开发者的视角，把前端缓存的完整体系拆开揉碎了讲一遍，从HTTP缓存到浏览器缓存，从Service Worker到CDN缓存，再到常见的坑和排查手段。不管你是刚入行的前端新人，还是已经在用Vue、React写业务但没认真研究过缓存的老手，都会有收获。如果你正在准备前端面试，这部分内容也是八股文里最高频的考点之一，看完能直接拿来当面试素材。

1. 缓存策略的核心思路：不是“存不存”，而是“存多久、怎么验”

很多前端开发对缓存的理解停留在“浏览器会自动缓存静态资源”这个粗浅层面。实际上，前端缓存是一套需要精心设计的系统工程，它的核心问题不是“要不要缓存”，而是三个更精确的问题：哪些内容需要缓存、缓存多长时间、以及缓存失效后怎么验证更新。

1.1 为什么前端必须要做缓存策略

先看一个很直观的数据。假设你的网站首页引用了20个静态资源，包括JS、CSS、图片、字体，总共约2MB。如果不做任何缓存策略，用户每次访问都需要从服务器重新拉取全部2MB内容，按普通4G网络1MB/s的实际传输速度来计算，光资源下载就要2秒多，再加上DNS解析、TCP建连、请求排队，首屏能达到3到4秒。这个体验在今天的互联网环境中基本属于劝退级别。

但如果做了缓存，情况就完全不同了。首次访问仍然是2MB全量加载，第二次访问时，浏览器直接从本地缓存读取大部分资源，网络请求体积可能降到几十KB甚至零请求。用户体感上的秒开，绝大多数不是服务器变快了，而是缓存把大部分网络开销省掉了。

从成本角度看，缓存对服务器的压力也是数量级的下降。一个日活10万的站点，如果没有缓存，静态资源的请求量会直接打到源站；有了缓存，90%以上的重复请求都可以在浏览器端或CDN边缘节点被消化掉。这也是为什么大厂在前端性能优化里，缓存策略永远是优先级最高的方案之一。

1.2 前端缓存的三个层次：HTTP层、浏览器层、应用层

做缓存方案之前，脑子里要有一张完整的地图。前端缓存不是一个单点，而是由三个层次协同构成的体系。

第一层是HTTP缓存，也就是浏览器和服务器之间通过HTTP头进行协商的缓存机制。这一层的核心是Cache-Control和ETag这些响应头。它解决的是“一个URL对应的内容能不能缓存、缓存多久、过期后怎么做验证”的问题。这一层对所有浏览器都生效，是整个缓存体系的基石。

第二层是浏览器本地存储，包括localStorage、sessionStorage、IndexedDB，以及Service Worker配合Cache API。它们解决的是“应用数据”和“离线可用”的问题。HTTP缓存管的是网络请求的资源文件，而Service Worker可以做到更精细的控制，比如在断网时返回缓存的页面、对特定接口做预取和缓存。

第三层是CDN缓存，它介于用户和源站之间。CDN节点会自动缓存源站返回的静态资源，用户就近从边缘节点获取内容，大大缩短网络传输距离。这一层表面上不属于“前端代码”的范畴，但它的缓存规则完全由前端和运维通过HTTP响应头来控制，所以做前端缓存策略时，CDN也是必须考虑的一环。

1.3 缓存方案的底层原则：先本地后网络，先强缓后协商

理解了三个层次之后，再来建立两条核心原则，这直接决定了你写配置和代码时的思路。

第一条原则是“先本地后网络”。用户请求资源时，优先从浏览器本地找，找不到或过期了才去网络拉取。这就是缓存能提速的根本原因。

第二条原则是“先强缓存，后协商缓存”。HTTP缓存分为强缓存和协商缓存两种。强缓存的意思是，在缓存有效期内，浏览器根本不发请求，直接用本地副本，连问都不问服务器。协商缓存的意思是，浏览器发现缓存过期了，于是带着缓存的标记去问服务器“我这个内容还能用吗”，服务器说“可以用”就返回304，浏览器继续用本地副本；服务器说“不可以”就返回200和新的内容。

这两条原则组合起来，就是一套完整的决策链。理解了这条决策链，你就能明白，前端缓存配置的所有参数、所有响应头，本质上都是在控制这条决策链上的某一个环节。

2. 核心细节：HTTP缓存机制的深度拆解

这一节是整个缓存体系里最核心、最考验基本功的部分，也是面试里最常被追问细节的地方。HTTP缓存本身不复杂，但细节非常多，每一条响应头的背后都有历史包袱和最佳实践，需要逐个吃透。

2.1 强缓存：Cache-Control和Expires的权衡

强缓存是性能收益最大的机制，因为它连请求都不会发。控制强缓存的响应头有两个：老牌的Expires和现代的Cache-Control。

Expires是HTTP/1.0时代的产物，它指定的是一个绝对时间，比如Expires: Wed, 21 Oct 2026 07:28:00 GMT。问题在于它的判断依据是客户端本地时间，如果用户把系统时间改乱了，缓存判断就会出错。所以现在的主流方案是用Cache-Control来替代它。

Cache-Control相对复杂一些，它有很多指令可以组合使用，但最核心的是这几个：

• max-age=31536000：从响应生成时刻起，缓存有效期为31536000秒（一年）。这是最常用的静态资源缓存时长。
• s-maxage=31536000：专门给CDN或共享缓存看的，优先级高于max-age。普通浏览器会忽略这个指令，但CDN节点会遵循它。
• public和private：public表示任何缓存（包括浏览器和CDN）都可以缓存；private表示只能浏览器私有缓存，CDN不能缓存，适合带用户信息的内容。
• no-cache：这个指令有点误导性。它不是说“不缓存”，而是说“缓存之前必须先验证”。也就是每次使用缓存副本之前，都要发请求去服务器确认内容是否新鲜。确认有效就304，不下载新内容。
• no-store：这个才是真正的“完全不缓存”。任何中间环节都不能保存副本，适合包含敏感信息的接口。

实际项目中最常见的组合是Cache-Control: public, max-age=31536000, immutable。其中immutable是个进阶用法，它告诉浏览器这个资源在过期之前是绝对不会变的，即使是用户手动刷新，也不要重新验证。这配合文件名指纹（比如app.8f3d2a.js）来使用时效果极佳。

2.2 协商缓存：ETag、Last-Modified和304的秘密

当强缓存过期之后，就轮到协商缓存上场了。协商缓存的设计目标不是“完全不传内容”，而是“用最小的代价判断内容是否变了”。

协商缓存有两个标准机制。第一个是Last-Modified / If-Modified-Since，服务器在响应头里返回资源的最后修改时间，浏览器在缓存过期后带上这个时间去问服务器“资源在这之后有变过吗”，如果没变，服务器返回304 Not Modified，响应体为空，浏览器继续用本地缓存。

第二个是ETag / If-None-Match，服务器为资源内容生成一个唯一的标识符（通常是内容哈希），浏览器在验证时带上这个标识符，服务器比较当前内容的标识符是否一致。

两者对比来看，ETag是更精确的机制，因为Last-Modified有天然的缺陷：文件修改时间精度是秒级的，如果在一秒内改了两次，或者文件内容变了但修改时间没变，就可能误判。另外ETag基于内容生成，即使在多台服务器负载均衡场景下也能准确判断。所以现代项目里ETag是主流，Last-Modified被当作兜底方案。

实际响应头配置里，比较标准的做法是后端框架自动生成两者。比如Nginx默认就会同时输出ETag和Last-Modified，而浏览器在协商阶段会优先使用ETag。

2.3 浏览器缓存决策链：一次请求的完整旅程

把强缓存和协商缓存串起来，就是一条完整的决策链。为了让你能记住，我用一个生活化的类比来解释。

可以把浏览器缓存放想象成冰箱里的食材。你接到一个做菜任务（请求一个JS文件），先看冰箱里有没有这个食材（看本地缓存），有的话再闻一下过期没有（看max-age），没过期就直接用（生效强缓存，200 from disk cache或memory cache）。过期了，就拿食材去问隔壁大厨（服务器）：这东西还新鲜吗（发请求带If-None-Match），大厨说没坏你继续用（304），坏了就给你新的（200）。

这条决策链对应到浏览器开发者工具里，就是你在Network面板里看到的三种状态：200 from memory cache、200 from disk cache、304 Not Modified。其中前两种是强缓存命中，第三种是协商缓存命中。

2.4 缓存配置参数选择的经验总结

参数选择没有绝对公式，但有非常成熟的项目经验可以参照。

静态资源（JS、CSS、图片、字体）这类内容的特点是文件名会随内容变化而变化（构建工具自动加哈希），它们是最适合激进缓存的，可以设置Cache-Control: public, max-age=31536000, immutable。因为名字变了就是新资源，名字没变内容一定没变，缓存一年完全没问题。

HTML文件要反着来，因为HTML是整个页面的入口，它的更新意味着页面结构的更新。如果HTML也被强缓存了，那用户就永远加载不到新的JS和CSS指纹。所以HTML一般设置Cache-Control: no-cache，确保每次请求都验证一下，但验证成本很低，304就行。

接口请求则要根据业务性质来区分。不敏感、变化不频繁的公共接口（比如配置信息、字典数据）可以设置短时间的强缓存；而用户相关的私有接口默认private, no-store或者no-cache，避免数据陈旧或泄露。热词里提到的“前端系统管理下的字典管理”，就是典型的适合接口缓存场景，字典数据本质上是低频变更的公共配置，缓存的收益非常明显。

3. 实操过程：构建一套完整的前端缓存体系

理论知识讲完，进入实操环节。这一节我会从构建工具配置、Web服务器配置、Service Worker、CDN四个维度，带着你把整条缓存链路一步步搭起来。

3.1 构建层：用文件名指纹解决“缓存更新”难题

先回答一个核心痛点：为什么我们用了一年max-age，改代码之后用户还是看到旧页面？答案在于文件名没有变化，浏览器认为“内容没变”就直接用了缓存。要解决这个问题，必须从构建层就为每个文件生成内容指纹。

以Webpack为例，生产环境的输出文件名一般这样配置：

js复制output: {
  filename: 'js/[name].[contenthash:8].js',
  chunkFilename: 'js/[name].[contenthash:8].chunk.js'
}

Vite用户则更简单，默认配置就是[name]-[hash].js，不需要手动处理。

这里的核心是contenthash，它是根据文件内容生成的哈希值。内容一变，哈希就变，文件URL就变了。浏览器根据URL去请求，发现是一个全新的URL，自然就不会命中旧缓存。这就是“文件名指纹”策略，也是解决“缓存更新难”的最根本手段，比版本号参数?v=1.0.2要精准得多，因为内容没变时哈希是稳定的，不会无故失效缓存。

另外还要注意runtimeChunk的配置。Webpack构建后，有个很小的runtime文件负责模块加载逻辑，它很容易变化。如果业务文件的内容变了，但runtime没跟着变，就可能导致新模块没有被正确加载。建议把runtime单独拆出来，或者使用runtimeChunk: 'single'，配合稳定的文件名策略，让它在每次重构时都能更新。这个细节点在面试里是加分项，实际项目中也是踩坑高发区。

3.2 服务器层：Nginx缓存配置实战

构建工具生成了带指纹的文件后，服务器端的Nginx配置就变成了缓存策略落地的关键。下面是一段生产环境可以用的Nginx配置：

nginx复制# 带指纹的静态资源：激进缓存一年
location /static/ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

# HTML文件：每次都去服务器验证
location / {
  add_header Cache-Control "no-cache";
}

# 不带指纹的图片资源：缓存7天，并启用协商缓存
location ~* \.(png|jpg|gif|ico)$ {
  expires 7d;
  add_header Cache-Control "public";
  etag on;
}

这段配置里有两个值得注意的点。第一，expires 1y是Nginx的语法糖，它内部会自动生成Cache-Control: max-age=31536000和Expires头。第二，HTML设置的no-cache是“每次都验证”，但验证需要靠协商缓存配合，所以Nginx默认开启的ETag会生效，验证的成本很低。

需要补充一个关键原则：带指纹的资源可以无限期缓存，不带指纹的资源必须设置合理的过期时间，绝不能无脑一年。如果什么都不改，给所有资源都设一年缓存，那下次改CSS文件时，文件名不变，用户会继续用旧文件，这就是最常见的“缓存不更新”事故。

3.3 应用层：Service Worker和应用缓存场景

HTTP缓存解决的是“文件层面的网络请求缓存”，但有些场景需要更细粒度的控制。比如离线访问、接口数据的预取、页面壳子的即时加载，这些就需要Service Worker进场了。

Service Worker的核心是拦截请求并决定响应从哪里来。它配合Cache API可以实现类似“应用程序缓存层”的能力。下面是一段典型的缓存优先策略代码：

js复制// service-worker.js
const CACHE_NAME = 'app-shell-v1';

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME).then(cache => {
      return cache.addAll([
        '/',
        '/index.html',
        '/static/css/app.css',
        '/static/js/app.js'
      ]);
    })
  );
});

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cached => {
      if (cached) {
        return cached;
      }
      return fetch(event.request).then(response => {
        return caches.open(CACHE_NAME).then(cache => {
          cache.put(event.request, response.clone());
          return response;
        });
      });
    })
  );
});

这段代码的逻辑是先查缓存，有就直接返回，没有就网络请求并把结果写入缓存。这是典型的Cache First策略，适合离线优先的应用。

但这里要特别提醒一个坑：Service Worker强制缓存了/index.html之后，即使你的Nginx对HTML设置了no-cache，浏览器也不会走HTTP协商流程，而是直接被Service Worker挡在门外，拿到旧版HTML。这会导致你部署新版本后，用户打开的是被Service Worker缓存的老壳子，但里面的JS文件已经指向最新指纹，结果就是页面白屏或报模块加载错误。

解决这个问题的思路是使用State While Revalidate策略，即先返回缓存，同时在后台更新缓存，下次请求就用新版本。更稳妥的做法是Service Worker在fetch时对HTML请求跳过Cache First，直接走网络。我这里有个经验之谈：Service Worker控制的范围越精准越好，不要一股脑缓存所有请求，HTML入口宁愿走网络验证。

3.4 CDN层：边缘节点缓存配置的关键点

如果你的业务面向全国甚至全球用户，CDN是绕不开的。CDN的原理很直观：用户请求静态资源时，就近的CDN节点如果缓存了该资源，直接返回，不再回源站请求。CDN只在节点缓存过期或未命中时才回源站拉取内容，并重新建立缓存。

要在CDN层做好缓存，核心还是控制响应头。CDN节点对Cache-Control的处理有两个关键指令：s-maxage专门控制CDN缓存时长，而public决定CDN是否允许缓存。

一个典型的配置思路是：在源站响应头里设置Cache-Control: public, max-age=31536000, s-maxage=31536000。对于普通的浏览器来说，它看到的是max-age一年；对于CDN节点来说，s-maxage同样是一年。这样浏览器和CDN都能充分发挥缓存作用。如果不希望CDN缓存某个接口，就设置Cache-Control: private, no-store，CDN见private就不缓存。

CDN层的另外一个坑是“缓存刷新”。很多运维同学上线新版本后，发现CDN节点还持有旧内容，需要在CDN控制台手动刷新缓存。这其实是缓存正常工作的表现，因为CDN节点要等到缓存过期才会回源。所以在发布流程里一定要设计“变更文件后同步刷新CDN路径”的步骤，或者使用带指纹的文件名，让新URL自动绕过旧缓存。很多团队用后者，这确实是最省心的方案。

3.5 接口数据的缓存策略：结合业务场景做判断

静态资源缓存只是前端缓存的一部分，接口数据的缓存往往被忽视，但它对用户体验的改善同样巨大。

对于低频变更的公共数据，比如字典管理里的字典列表、城市列表、配置参数，可以设置短时间的强缓存。示例响应头是Cache-Control: public, max-age=300，5分钟内用户看到相同的结果，但接口不会反复请求服务器。

对于用户数据，比如个人信息、订单列表，就要谨慎了。这类数据既敏感又实时，如果被中间层缓存了，用户A的数据可能泄露给用户B，这是严重的事故。所以这类接口必须设置Cache-Control: private, no-store，明确禁止任何缓存环节保存响应内容。

还有一类是可以接受短时延迟的实时数据，比如排行榜。它更新频繁但用户对分钟级延迟并不敏感，可以用Cache-Control: public, max-age=60，让CDN缓存1分钟，大幅降低源站压力。

这里有一个实用的面试技巧：如果你在面试中被问到HTTP缓存的应用场景，不要只背定义，而是按静态资源、HTML、公共接口、用户接口四种类型分别说明对应的Cache-Control配置和理由。这比只回答“强缓存和协商缓存的区别”要高级得多，也更能体现你的工程项目经验。

4. 常见问题与排查技巧实录

缓存机制虽然强大，但坑非常多。我把自己在实际项目里踩过的、以及在社区里高频出现的缓存问题统一整理了一遍，逐条说明原因和解决方案。

4.1 改完代码重新部署，用户还是老页面

这是最常见的问题。排查思路很简单：先看用户访问的URL是不是新的。如果HTML页面没变化，JS、CSS引用的还是旧文件名，那说明用户的浏览器还在使用缓存的HTML。解决办法是给HTML设置no-cache，确保每次请求都验证。如果HTML已经是新的，但里面的静态资源URL没变化，那说明构建指纹配置没生效，去检查contenthash配置。

还有一种情况，用户确实在下一次请求时拿到了新HTML，但JS文件是旧的，这是因为带上旧指纹的JS文件已经被强缓存了。这种情况下，只能依赖文件名指纹的新URL来绕开旧缓存。所以每次更新必须保证HTML引用的资源URL出现新指纹，这是整个缓存体系里最核心的一环。

排查工具：Chrome DevTools的Network面板。在Network里点一个请求，看Headers，如果看到“Provisional headers are shown”，说明请求没有真正发出，是浏览器直接用的缓存，这是判断强缓存最直接的依据。

4.2 304和200 from disk cache有什么区别，为什么有人分不清

这个问题我面试别人时问过很多次，能把这两个概念讲清楚的人不多。一句话总结：304是协商缓存命中，浏览器发起了请求，服务器回复“内容没变，别下载了”；200 from disk cache是强缓存命中，浏览器压根没发请求，直接用的本地文件。

在Network面板的表现上，304的Size列显示是(from disk cache)或者(304)，实际传输字节数非常小；强缓存的Size列是(from memory cache)或(from disk cache)，但没有网络请求。知道这个区别之后，排查问题时一眼就能判断缓存命中的层级。

4.3 用户反馈数据不对，但服务端日志正常

这种情况大概率是中间层缓存了动态接口。我遇到过一次真实事故：一个运营后台改了配置数据，但前端页面怎么刷新都是旧值，服务端日志也没有异常。后来发现是CDN对这个配置接口做了缓存，缓存时间还没过期，所以用户一直拿到的是旧数据。排查办法是使用curl直接请求源站接口，跳过CDN，看返回内容和响应头；再对比通过CDN域名请求的响应头，就能看出是不是被CDN的缓存头影响了。

这类问题的系统性解法是：核对源站接口的Cache-Control是否带了private或no-store，同时观察CDN侧是否强行覆盖了缓存策略。有些CDN配置了“自定义缓存规则”，可以无视源站的Cache-Control，这需要和运维同学对齐。

4.4 Service Worker导致页面无法更新

这个问题在PWA项目里很典型。症状是：开发者工具里关了缓存，强刷了页面，代码也改了，但页面还是旧行为。原因就是Service Worker还活着，并且接管了页面请求。Service Worker的生命周期很长，即使关闭所有页面，它也可能在后台存活一段时间。

排查手段是打开Chrome DevTools的Application面板，找到Service Workers，直接点击Unregister注销掉，再清一次缓存存储，然后刷新页面。但这是手动手段。真正的解法还是要设计好Service Worker的更新机制，核心是install阶段完成后调用self.skipWaiting()，activate阶段调用self.clients.claim()，并让页面监听Service Worker更新事件，提示用户刷新页面。

4.5 清理缓存的快捷技巧和工具

日常开发中，有几个高频的缓存清理手段值得记住：

• 无痕窗口访问网站，这是最快速的、绕过所有缓存的验证方式。
• DevTools的Network面板勾选Disable cache。注意这个选项只在开发者工具打开的状态下生效。
• Application面板下的Clear storage按钮，一键清掉本地存储、缓存存储、Service Worker等全部数据。
• 使用curl命令直接查看响应头，验证服务器端配置是否正确，比如curl -I https://example.com/static/js/app.abc.js。
• 如果需要精细排查，可以加上?v=时间戳这样的参数临时绕过缓存，但这只能用于本地调试，生产环境依赖这个是不靠谱的。

这些技巧看起来基础，实际排查效率很高，强烈建议记住。

5. 前端缓存方案的整体避坑清单

把整套方案放进一张表里，方便你实际项目中对照检查。

这里根据我自己的项目体验，还有三个额外的避坑心得想分享。

第一个心得是不要迷信“缓存越大越好”。有些团队把图片、字体、CSS全部缓存一年，结果某天要做一次页面改版，全站资源文件名没变，用户哭天喊地看不到新界面。带指纹的资源缓存一年是安全的，不带指纹的默认保守一点，7天已经是比较激进的设置了。

第二个心得是发布流程里一定要有“缓存预演”环节。上线前先测试各个缓存层是否按预期生效：用curl查看响应头、检查CDN刷新结果、确认新资源指纹出现在新HTML里。这一套流程只要每个版本都固定执行，缓存事故率会降到很低。

第三个心得是可以在前端埋一个“版本号机制”：在HTML里写一个全局变量，比如window.__APP_VERSION__，部署时把它改为当前版本号，前端代码里可以监测版本变化，然后提示用户刷新页面。这个技巧虽然简单，但在处理“用户长期开着老标签页不刷新”的场景时特别有效。

跟我合作过的一个后端同学说过一句话，我印象深刻：“你们前端项目最明显的优化，不是代码写得多优雅，而是缓存策略到位了，服务器压力直接降了一个量级。”前端缓存策略就是这样一项投入小、收益极大的工程，它不要求你懂多么复杂的算法，但需要你把HTTP协议的细节吃透、把构建工具的原理搞清楚、把发布流程设计顺畅。这三者结合起来，网站自然就飞起来了。

最后再分享一个实战里经常用到的小技巧：排查缓存问题时，别只在浏览器里刷新，配合curl看原始响应头、用无痕窗口模拟首次访问、再到Network面板确认是强缓存还是协商缓存命中的，三步下来，90%的缓存问题都能精准定位。前端缓存不是玄学，它是一套可以参考、可以复现、可以验证的工程方法，掌握了它，你的项目体验和面试表现都能往上走一个台阶。