企业官网建设流程全解析

2. 缓存体系全景：先搞清楚你有哪些牌可打

2.1 前端缓存的五大层：HTTP缓存、浏览器存储、Service Worker、CDN与内存缓存

做前端优化，第一个要建立的概念就是：缓存不是一个单一机制，而是一整套分层体系。从用户发起请求到最终渲染页面，中间至少经过五层缓存，每一层负责的职责和时效完全不同。

第一层是HTTP缓存，也是我们最常说的强缓存和协商缓存。这一层由浏览器内置的缓存机制驱动，核心是响应头里的Cache-Control、Expires、ETag、Last-Modified这些字段。页面里的JS、CSS、图片、字体这些静态资源，大部分性能收益都来自这一层。

第二层是浏览器本地存储，包括localStorage、sessionStorage、IndexedDB。这一层适合存业务数据、接口响应快照、用户偏好设置等。它不是给静态资源用的，而是给"业务数据"用的。

第三层是Service Worker，这是PWA的核心技术之一。它本质是一个运行在浏览器后台的JavaScript线程，可以拦截所有页面请求，自己决定从缓存返回还是走网络。配合Cache API，可以做到完全离线访问。

第四层是CDN缓存，属于基础设施层面的缓存。静态资源部署到CDN边缘节点后，用户就近获取资源，这部分收益是"物理距离"换来的，跟浏览器本身关系不大。

第五层是内存缓存，比如浏览器内部的memory cache，以及Vue/React应用里的状态管理数据。这一层最容易被忽略，但恰恰是SPA应用里最关键的一层。

这五层不是非此即彼的关系，而是层层递进、按优先级排列的。一张完整的缓存策略表应该是：先看Service Worker，再看HTTP缓存，然后走CDN，最后落到源站。每一层命中不了再往下一层走。

2.2 性能提升30%是怎么算出来的：一个真实的量化过程

标题里写"性能提升30%"，这不是拍脑袋的数字。我在实际项目中做过一个相对严谨的量化测算，这里把方法分享出来。

假设你的页面加载了一个2MB的JS bundle和500KB的CSS文件，合计2.5MB静态资源。在没有缓存的情况下，用户每次访问都要从服务器拉取这2.5MB。如果把这些资源设置为强缓存一个月，第二次访问时浏览器直接走磁盘缓存，网络传输体积变为0。

用Chrome DevTools的Network面板实测一下：无缓存情况下，DOMContentLoaded时间可能是1.8秒，首次加载完成时间3.2秒；有缓存的情况下，第二次访问DOMContentLoaded时间直接掉到300毫秒以内。这个差距就是30%以上的性能提升来源。

再算一笔接口层面的账。假设一个管理后台首页有8个接口，总响应体量约600KB，接口数据加上了Cache-Control: max-age=60的缓存策略，用户在1分钟内重复访问，这8个接口全部命中浏览器缓存，接口耗时从平均400毫秒降到个位数毫秒。整体白屏时间缩短一半都不止。

所以说"30%"是一个非常保守的数字，如果你的页面资源体积大、接口重复请求多，优化空间甚至能到50%以上。但要特别注意一个前提：缓存不是无脑开启的，设置不当会造成页面更新不及时、数据陈旧等更严重的问题。这就是后面要重点讲缓存失效和缓存一致性的原因。

3. HTTP缓存深入：强缓存与协商缓存的完整拆解

3.1 强缓存：浏览器说了算，根本不发请求

先讲强缓存。强缓存的特点是：只要缓存没过期，浏览器压根不会向服务器发任何请求。你怎么知道它没请求？打开DevTools的Network面板，看资源的Size列，显示"from disk cache"或"from memory cache"就是命中强缓存，状态码是200。

控制强缓存的是两个响应头：Cache-Control和Expires。Expires是老一代的字段，格式是绝对时间，比如Expires: Wed, 21 Oct 2025 07:28:00 GMT。它的问题在于浏览器时间和服务器时间可能不一致，时间不同步就会出现缓存提前失效或延迟失效的问题。所以现在基本被Cache-Control取代了。

Cache-Control里面有这么几个关键指令：

• max-age=3600：缓存有效期为3600秒，这是相对时间，以浏览器收到响应的时间为基准
• public：响应可以被任何中间节点缓存，包括CDN
• private：响应只能被浏览器私有缓存，CDN不缓存
• no-cache：注意，这个指令不是说不缓存，而是说"使用缓存前必须先到服务器验证一下"
• no-store：这才是真正的不缓存，任何环节都不保存

实际配置中，我一般用Cache-Control: public, max-age=31536000来缓存带版本号的静态资源。为什么是31536000秒？就是一年，因为文件名带了hash，内容变了文件名就变了，所以可以放心地设置超长时间。

3.2 协商缓存：每次请求都去问服务器，但可以少传数据

协商缓存的逻辑是：浏览器每次都向服务器发一个请求，问"我这个资源能复用吗？"服务器说能，就返回304状态码，但不返回资源体本身；服务器说不能，就返回200和新的资源体。

协商缓存有两个机制，一个基于Last-Modified和If-Modified-Since，一个基于ETag和If-None-Match。

Last-Modified是服务器返回的资源最后修改时间，浏览器下次请求时带上If-Modified-Since: <资源修改时间>，服务器把这个时间跟自己手里的文件修改时间比对，一致就返回304，不一致就返回200新资源。这个方案实现简单，但有一个明显的坑：如果文件修改时间变了但内容没变，会触发一次不必要的重新下载。

ETag解决的就是这个问题。服务器根据文件内容生成一段唯一标识，内容变了ETag才变。浏览器请求时带上If-None-Match: <ETag值>，服务器比对ETag，一致返回304，不一致返回200。ETag的粒度可以精确到文件内容级别，比Last-Modified更准确。

实战中我推荐的做法是：静态资源只用强缓存，不配协商缓存；HTML页面用协商缓存，确保用户拿到最新入口文件的同时，也能跳过重复下载。这个组合能兼顾性能和更新及时性。

3.3 实战配置：Nginx场景下的缓存头设置

以Nginx为例，一个典型的缓存配置长这样：

# 带hash的静态资源，一年强缓存 location /static/ { expires 1y; add_header Cache-Control "public, max-age=31536000, immutable"; } # HTML页面，协商缓存 location / { add_header Cache-Control "no-cache"; etag on; last_modified on; }

这里immutable是一个比较新的指令，它告诉浏览器：这个资源在过期之前内容一定是不会变的，你可以放心大胆地用，连刷新页面都别重新请求。这个指令对带hash的文件非常适用。

还有一类特殊场景：SPA应用的入口HTML。Vue或React构建出来的dist/index.html，引用的JS和CSS都带hash，但HTML本身每次构建都会变。如果HTML被强缓存了，用户就会一直拿到旧的页面，引用旧的资源文件。正确的做法就是no-cache加ETag，让浏览器每次访问都去服务器确认一次，确认HTML没变才走缓存，变了就发新HTML。

3.4 缓存穿透、缓存雪崩与缓存击穿：后端概念的前端映射

说个有意思的事。很多人以为缓存穿透、缓存雪崩是后端Redis的场景，跟前端没关系。但我在做分布式缓存治理和接口优化时发现，前端同样会遇到类似的三个问题。

缓存穿透体现在前端就是：你的请求因为参数不同，每次都无法命中缓存，导致每次都全量请求。比如搜索引擎的关键词搜索，100个用户搜100个不同的词，每个词都产生一次真实请求，缓存完全失效。前端缓解的办法是对高频请求做本地缓存兜底，手动实现LRU缓存策略，只缓存最近最常用的N条数据。

缓存雪崩在前端的表现是：当缓存集中过期时，瞬间大量请求打到后端。比如本地存储的接口数据设置了统一的5分钟过期时间，5分钟一到，所有用户的页面同时刷新，后端压力瞬间翻倍。解决方法是错开过期时间，比如在缓存时间上加随机偏移量。

缓存击穿则对应"热点数据过期瞬间并发打爆单点"的场景。前端通常用短期锁或快速降级方案来应对，同一时刻只允许一个请求去更新缓存，其余请求暂时用过期数据。

这三类问题其实也是前端面试题里特别爱考的，面试官往往拿着后端概念来考前端候选人能否融会贯通。理解了这三类问题，你回答这类问题时能明显比只会"背八股"的人高一个段位。

4. 浏览器存储实战：从Cookie到大对象

4.1 LocalStorage、SessionStorage与IndexedDB的选型思路

浏览器存储这块，面试和实战都绕不开三个兄弟：localStorage、sessionStorage、IndexedDB。先摆一张对比表：

我自己的选型经验是：能用localStorage解决的问题就别上IndexedDB，因为IndexedDB的API是异步的，代码复杂度上了一个台阶。但反过来，你要是想缓存上百MB的音频、视频切片，或者需要索引查询大量结构化数据，localStorage就完全不够用了，必须上IndexedDB。

有个细节很多人忽略：localStorage是同步读写的。这意味着如果你在一个关键渲染路径里同步读取几MB的数据，会阻塞主线程。最好的做法是能存小数据就存小的，大对象别硬塞localStorage。

再补充一个真实场景：前端SDK的数据持久化。我们开发过一个内部统计SDK，需要上报用户行为数据，同时要保证即使网络不稳定也不能丢数据。方案就是先把数据写入IndexedDB，然后由后台的同步任务轮询上传，传成功就删除。这个方案的可靠性远超直接用localStorage拼接字符串，IndexedDB的事务能力保证了写入的完整性。

4.2 接口数据缓存：手写一个带过期时间的缓存管理器

接口数据缓存是我在实际项目里用得最多的缓存手段，尤其是管理后台这种接口重复请求频率极高的场景。比如用户每切换一次菜单就重新拉一遍全部字典数据，完全是浪费。

我手写过一个简单的缓存管理器，核心代码量很小：

class CacheManager { constructor() { this.cache = new Map(); } set(key, value, ttl = 60000) { this.cache.set(key, { value, expire: Date.now() + ttl }); } get(key) { const item = this.cache.get(key); if (!item) return null; if (Date.now() > item.expire) { this.cache.delete(key); return null; } return item.value; } // 错开过期时间，避免缓存雪崩 setWithJitter(key, value, ttl = 60000) { const jitter = Math.random() * 30000; this.set(key, value, ttl + jitter); } }

这个管理器用内存Map存储，配合TTL控制有效期。要注意的是，内存缓存刷新页面就没了，如果要做跨页面持久化，把底层存储换成localStorage即可，核心逻辑不变。

4.3 IndexedDB在复杂业务场景中的落地：大文件、离线数据与增量更新

IndexedDB最能体现价值的地方有三个：大文件分片存储、离线数据支撑、增量数据更新。

先说大文件分片。项目里有个需求是上传几十MB的附件，断网后要能自动重试。我们把文件切成1MB的分片，先存到IndexedDB，然后由上传模块逐个上传，传成功的分片标记删除，下次断点续传只看未传的分片。这套方案完全绕开了网络波动对用户的影响。

再说离线数据。我们做过一个面向门店营业员的H5应用，门店网络经常不稳定。方案是把商品库、库存信息同步到IndexedDB里，页面优先读本地数据，网络恢复后再增量更新。实测下来，弱网环境下页面的可用性提升非常明显，从"经常白屏"变为"基本可用"。

最后说增量更新。每次接口返回大量数据时，我们会对数据生成一个版本号或者时间戳，客户端只拉取增量部分，再跟本地的数据做合并。合并逻辑放在IndexedDB的事务里，保证数据一致性。这个思路对应的就是后端常说的缓存一致性维护。

使用IndexedDB有四个重要的注意点：

• 回调地狱问题，建议用Promise封装甚至直接用idb这个工具库
• 所有操作都是异步的，不要在循环里同步等待操作结束，要合理利用事务
• 版本升级时要写迁移逻辑，否则不同版本的用户可能出现数据结构不一致
• 隐私模式隐身窗口下IndexedDB可能不可用，代码里要兼容异常情况

5. Service Worker缓存：前端的终极武器

5.1 Service Worker的注册、安装与生命周期

如果说HTTP缓存是"被动接收"的话，Service Worker就是"主动操控"。它可以拦截页面发出去的所有请求，自己决定怎么响应。

生命周期是这么走的：注册->安装->激活->接管页面。注册发生在页面主线程，安装和激活发生在Service Worker线程。注意一个重点：Service Worker默认不会接管当前页面，需要clients.claim()或者等下一次导航时才生效，这个细节经常让新手产生"我怎么注册了不生效"的困惑。

一个最基本的注册代码：

// 注册 if ('serviceWorker' in navigator) { window.addEventListener('load', () => { navigator.serviceWorker.register('/sw.js') .then(reg => console.log('Service Worker registered')); }); }

注册的路径很关键，/sw.js表示作用域是整个站点根目录。如果放在/assets/sw.js，作用域只有/assets/，就影响不到页面本身的请求。

5.2 三种核心缓存策略：Cache First、Network First、Stale-While-Revalidate

Service Worker的核心设计是缓存策略。我在真实生产环境里用得最多的是下面三种：

第一种：Cache First，缓存优先。命中缓存就直接返回，不碰网络。适合图片、字体、版本号固定的静态资源，速度最快，但更新不够及时。

第二种：Network First，网络优先。先发请求，网络成功就用网络返回并更新缓存；网络失败才回退到缓存。适合HTML页面、接口数据这类需要保证最新的内容。

第三种：Stale-While-Revalidate，滞后刷新。立即返回缓存里的旧数据显示在页面上，同时后台发一个请求更新缓存，下次访问就是新数据了。这个策略非常优雅，既快又不牺牲数据新鲜度，适合大部分接口数据。

第三种的代码实现也非常简洁：

async function staleWhileRevalidate(request) { const cache = await caches.open('api-cache-v1'); const cachedResponse = await cache.match(request); const networkPromise = fetch(request).then(networkResponse => { cache.put(request, networkResponse.clone()); return networkResponse; }); // 先返回缓存的，但没有缓存时才走网络 return cachedResponse || networkPromise; }

这个模式在业界还有个别名，叫SWR，有个知名React数据请求库就叫这个名字。理解了Service Worker的SWR策略，你就更容易理解前端数据请求库为什么要这样设计了。

5.3 前端H5应用接入Service Worker的完整流程

H5应用接入Service Worker，我整理了一个完整的落地流程：

第一步，构建阶段生成资源清单。用Webpack的workbox-webpack-plugin插件，构建时自动生成precache清单列表，把带hash的静态资源全部列进去。

第二步，注册预缓存。Service Worker安装阶段把清单里的资源全部拉取到Cache Storage里面，这一步完成之后，所有缓存资源都在本地了。

第三步，运行时缓存策略配置。HTML页面用Network First，JS和CSS用Cache First，图片用Stale-While-Revalidate，接口请求按照业务需要单独配置。

第四步，版本管理与主动更新。Service Worker文件本身不要缓存，每次发布新版本时文件名中的hash变化，Service Worker安装的缓存清单也会变。配合skipWaiting和clients.claim()，可以实现新版本发布后用户下次打开页面就自动更新到最新。

这里给一个workbox的配置片段：

// workbox.config.js const { generateSW } = require('workbox-build'); generateSW({ globDirectory: 'dist', globPatterns: ['**/*.{js,css,html,png,svg,ico}'], swDest: 'dist/sw.js', runtimeCaching: [ { urlPattern: /\.(png|jpg|jpeg|svg|gif)$/, handler: 'CacheFirst', options: { cacheName: 'image-cache', expiration: { maxEntries: 60, maxAgeSeconds: 30 * 24 * 60 * 60, }, }, }, { urlPattern: /\/api\//, handler: 'StaleWhileRevalidate', options: { cacheName: 'api-cache', }, }, ], });

这段配置里我特别加了expiration约束，避免缓存无限增长占用太多磁盘空间。最大条目限制和最大存活时间这两个参数是线上环境必配的。

6. 缓存失效与更新：最容易翻车的地方

6.1 文件名Hash与版本管理：缓存的最佳实践组合

缓存的痛点是：性能和数据新鲜度天然矛盾。缓存时间设长了更新慢，设短了性能收益低。解决这个矛盾的最佳实践就是：文件名Hash加上强制缓存。

Webpack和Vite构建时都会自动给文件名加上内容hash，比如app.8d3k2f9.js。文件内容变，hash就变，浏览器请求的URL也就变了，自然绕开旧缓存。这种方案让资源可以放心设置一年缓存，因为只要URL变了就一定拉新文件。

关键的坑在于HTML入口文件。HTML不能加hash，每次构建都是同一个index.html，所以HTML必须用协商缓存或者no-cache，确保每次访问都回源校验，拿到最新的资源引用URL。如果HTML被强缓存了，就会出现用户打开页面用的是旧HTML里记录的旧文件URL，永远加载不到新代码。

我之前在Vue项目里遇到过一个典型的缓存事故：Nginx配置了index.html强缓存一个月，发布新版本后，大部分用户反馈页面还是旧版。排查过程就是先看HTML响应头，发现Cache-Control: max-age=2592000，然后果断改成no-cache，再发布，问题立刻解决。

6.2 缓存不一致的四个常见场景与解决思路

在我排查生产环境问题的时候，缓存不一致主要集中在以下四个场景：

场景一：登录状态异常。用户退出登录后，再次登录另一个账号，页面却还显示旧账号的数据。原因可能是旧账号的数据被localStorage持久化了，新账号启动时没有清空。解决方案是登录登出时显式清理关键缓存的key，不要把清理逻辑完全依赖于服务器下发的最新数据。

场景二：接口列表查询条件变化。同一个接口URL，参数不一样，缓存却共用了。比如/api/list?status=1和/api/list?status=2两个请求URL不同，浏览器不会搞混，但如果你手动用URL做缓存key却忽略参数，就会出现数据错乱。方案是缓存key必须由完整URL加参数构成，或者直接用请求前后拼接MD5作为唯一key。

场景三：多端同步不及时。用户在A设备上修改了数据，B设备缓存里还是旧数据。HTTP缓存和本地存储都管不到这个，只能靠接口数据污染策略弱化冲突，或者引入轮询机制定期校验。

场景四：部署回滚后的缓存残留。版本回滚后，新版本资源和上一个版本资源hash不一致。浏览器缓存里可能同时存在多个版本的文件，页面引用顺序混乱就会导致CSS和JS版本不匹配。解决方案是每次发布前检查关键静态资源的hash是否跟预期的一致，回滚后对受影响用户做一次缓存版本的强制刷新。

6.3 强制刷新的正确姿势：控制台、代码升级与灰度发布

面试里经常被问到"线上代码更新了，用户还是旧版本，怎么办"，我给出的方案排序是这样的：

第一步，确认缓存策略没有硬伤。检查HTML是不是no-cache，静态资源是不是设置了合理的max-age。如果策略本身就是错的，刷新再多次都没用。

第二步，短期手动刷新。告诉用户强制刷新快捷键，Windows是Ctrl+Shift+R，Mac是Cmd+Shift+R。或者开发者在DevTools里勾选Disable cache再刷新，这只影响开发者自己，对线上用户无效。

第三步，代码级别应急重置。如果缓存问题波及面大，可以在HTML里临时加一个版本参数，比如<script src="/app.8d3k2f9.js?v=20240101">，强制所有用户拉新资源。但要记住这只是应急手段，下个版本要移除。

第四步，灰度发布与版本监听。业务平台可以做灰度发布，先放5%的流量，观察缓存和版本情况再全量放量。前端可以做版本监听，比如定期请求一个版本号接口，发现版本变化时弹窗提示用户刷新页面。这个方案在uni-app做跨端开发时也适用。

6.4 从MyBatis缓存到前端缓存：多端缓存设计的一致性思路

这里忍不住多说一句。因为工作原因，我也接触过后端的缓存体系，比如MyBatis缓存、Redis缓存治理、Spring三级缓存。后端很多思想跟前端是共通的。Spring的三级缓存解决的是循环依赖问题，核心思想是"不要重复创建，能复用就复用"；MyBatis的二级缓存解决的是"同一个查询不要重复查数据库"。

这些思想映射到前端就是：能复用就不重算，能本地取就不发网络请求。分布式缓存里的缓存穿透、缓存击穿、缓存雪崩，映射到前端就是我前面讲的那三种情况。理解了这套底层逻辑，无论你用的是Vue、React还是原生JavaScript，都能把缓存策略用对。

7. 性能优化验证：30%是怎么测出来的

7.1 DevTools Network面板的三种缓存命中标识

要验证缓存策略生效没有，Chrome DevTools是最常用的工具。Network面板里，缓存命中有三种显示方式：

from memory cache：资源从内存缓存中读取，速度最快，一般在当前页面内第二次请求会出现。

from disk cache：资源从磁盘缓存读取，速度快，刷新页面后第二次请求大多走磁盘。

304 Not Modified：走协商缓存，服务器确认资源没变，不返回资源内容，网络耗时极短但不是零。

我日常的排查步骤是：用一个页面的静态资源列表做样本，看这些资源是走了200带内容、200走缓存、还是304。如果大量资源还停留在"200 + 下载完整内容"的状态，说明缓存策略没配上位。

7.2 Lighthouse与Performance面板的量化对比方法

光看Network还不够，想真正量化性能提升，还得用Lighthouse和Performance面板。

实操方法很简单：确定一个基准版本，先在不带任何缓存策略的版本上跑三次Lighthouse，记录Performance分数和关键指标（LCP、FCP、Speed Index、TBT）。然后加上缓存策略，再跑三次，对比平均值。同一个项目前后版本对比，把网络从缓存命中改为Slow 4G，这样排除了网速波动的影响，对比才有意义。

Performance面板能更精细地观察每个阶段的耗时。在Performance录制后，看"Rendering"和"Network"两个泳道，能直观看到缓存命中和未命中情况下资源加载时长的差异。通常缓存命中后，主文档到FCP的时间能减少80%以上。

7.3 一个真实项目的优化前后数据对比

我之前优化过一个电商活动H5页面，核心操作就三条：静态资源加一年强缓存、接口数据加8分钟缓存、HTML改协商缓存。

优化前的数据（平均值）：首屏加载时间3.5秒，接口总耗时1.2秒，DOMContentLoaded 2.1秒。

优化后的数据：首屏加载时间1.8秒，接口总耗时0.3秒，DOMContentLoaded 0.6秒。

注意，这是新用户首次访问的对比。老用户二次访问时区别更夸张：由于HTML没有变化，静态资源和大部分接口都走了缓存，首屏时间能压到0.8秒以内。整体感知就是"优化后页面秒开"。按首屏时间算降幅接近50%，保守说30%完全站得住。

8. 避坑指南与常见问题速查

8.1 五个容易忽视的细节

我在帮朋友团队Review代码时，发现缓存方面的坑翻来覆去就那几个，这里集中整理一下。

第一个坑：token存localStorage的安全隐患。localStorage是明文存储且任何同源脚本都能读取。一旦被XSS攻击注入脚本，token就泄露了。更安全的做法是把token放在内存或Cookie里，加httpOnly和Secure标记。又要持久又要安全的话，可以考虑IndexedDB加加密存储，但这套方案复杂一些，适合对安全要求高的项目。

第二个坑：CDN缓存和浏览器缓存混为一谈。CDN缓存是边缘节点的缓存，跟浏览器本地缓存完全两个层面。浏览器缓存命中后根本不会经过CDN；浏览器缓存未命中请求到CDN节点，CDN也可能直接返回边缘缓存内容。配置时两个层面都要设置清楚的Cache-Control，不然可能出现"源站更新了，CDN不刷新"和"CDN没更新，浏览器一直拿着旧资源"的双重问题。

第三个坑：缓存量与磁盘空间的平衡。IndexedDB和Cache API持续膨胀，用户磁盘空间告急。解决方案是给缓存设置上限，比如IndexedDB定期清理N天前数据，Cache Storage的条目数和大小用expiration限制。Service Worker里使用完缓存后要主动调用caches.delete()清理旧缓存，不能光存不删。

第四个坑：隐私模式与隐身窗口的表现不一致。隐身模式下localStorage依然可用，但不同浏览器策略不同，有些场景IndexedDB会不可用。调试时如果发现缓存不生效，先排除是不是开了隐私模式，再检查是不是无痕模式下存储被禁用了。

第五个坑：iframe内的缓存不共享。如果你用qiankun微前端，子应用跑在iframe或沙箱环境里，存储共享问题就比较复杂。qiankun默认是把localStorage/ sessionStorage代理到主应用上共享的，但静态资源的缓存策略还跟普通站点一致。微前端架构下，更建议在主应用统一管理缓存的清理与策略，避免子应用各自为政。

8.2 生产环境缓存问题排查清单

遇到"页面加载不对"的问题，我有一套固定的排查顺序，分享出来：

先看HTML响应头，确认Cache-Control是不是no-cache，这一步能排除90%的更新不及时问题。

再看引用的静态资源URL里有没有hash，后缀的版本参数是否是有效变化的。

然后打开Network面板刷新页面，看资源和接口有没有命中缓存，没有就检查响应头的缓存字段是否正确。

接着对比线上环境与本地代码版本号，确认发布流程是否真的把新代码部署上去了，很多"缓存问题"其实是发布失败。

最后检查Service Worker是不是在拦截请求，Cache Storage里是否存在旧版本数据的残留。

按这个清单走下来，绝大多数问题都能在10分钟内定位到根因。

8.3 三个缓存相关的经典面试题思路

顺手梳理一下前端面试里高频出现的缓存题，给准备面试的朋友一个参考角度。

第一题："强缓存和协商缓存的区别是什么？"回答重点在于强缓存不发请求、协商缓存每次发请求，以及两者对应的HTTP字段和适用场景。再补一句强缓存校验的是时间规则，协商缓存校验的是内容状态，能加分。

第二题："如何实现一个完美的前端缓存更新方案？"核心思路是先聊HTML与静态资源的拆分策略，HTML走协商缓存，静态资源走hash加一年强缓存，再补充Service Worker做主动更新，最后提灰度发布措施。整条链路清晰完整，面试官一听就知道你搞过落地。

第三题："localStorage和Cookie的区别？"除了容量大小这些基础差异，重点强调Cookie会自动随HTTP请求发送到服务器，有安全和性能开销，localStorage完全保存在客户端，不会自动带着走。再补充一下各自的典型适用场景。

9. 最后分享一点实际经验

做了这么多年前端，我的体会是：缓存是性能优化中投入产出比最高的一环，但也是最容易"设置完就忘了"的一环。很多团队上线完功能就不再看缓存配置，直到哪天用户反馈"页面怎么还是旧的"才想起来排查。

我自己的习惯是：每次发版需求单里固定写一条"缓存策略检查"，发布前确认Nginx配置和Service Worker版本是否更新，发布后跑一遍DevTools看缓存状态是否正常。这个习惯帮我们避开了好几次线上事故。

另外一个可以分享的小技巧是：在应用里加一个隐藏的"版本号"信息，比如在index.html里注入一个meta标签标记构建时间，或者在登录后的response头里带一个app-version。排查问题时，你让用户把版本号发过来，立刻就能判断对方到底跑的是哪个版本，省掉很多无效沟通。

缓存这块的知识面其实不小，从HTTP头到浏览器存储到Service Worker再到CDN，每一层都有独立的技术细节。但只要你把"分层理解、按需配置、勤于验证"这三个原则记在脑子里，不管项目简单还是复杂，都能做出靠谱的缓存方案。