浏览器缓存,配置得当,它能让页面飞起来;配置错了,一次小小的上线,就能把你扔进线上 bug 的坑里。你可能遇到过这些情况:
- 部署上线了,结果用户还在加载旧的 JS;
- 接口数据改了,页面却还拿着几分钟前的老版本;
- Service Worker 缓了一大堆东西,结果连新页面都加载不出来......
一、浏览器缓存到底是怎么一回事?
别被"缓存"两个字骗了,它不只是简单地"存一下资源"。
浏览器的缓存机制其实是分层的,而且各层的策略和触发条件都不一样:
1.1 三类缓存存储层
|--------------------------|-------------|---------------|
| 缓存类型 | 生命周期 | 典型用途 |
| Memory Cache | 页面打开期间,关闭即清 | JS/CSS 快速复用 |
| Disk Cache | 浏览器层面,长期有效 | HTML、图片等 |
| Service Worker Cache | 自定义、可离线 | PWA 场景或定制缓存策略 |
1.2 两种核心缓存逻辑
浏览器判断一个资源能不能用缓存,基本分这两种逻辑:
✅ 强缓存(直接用,不发请求)
通过 HTTP 响应头:
Cache-Control: max-age=31536000
或者:
Expires: Wed, 21 Oct 2025 07:28:00 GMT
只要浏览器还在有效期内,连请求都不发,直接从缓存取资源。
✅ 协商缓存(发请求,看是否要更新)
如果没命中强缓存,浏览器会尝试和服务器协商资源是否变了:
If-None-Match: "e1d3f...etag"
如果服务器返回 304,说明资源没变,浏览器用本地缓存;否则重新拉。
二、常见"缓存坑"还原现场
🧨 场景一:JS 改了,用户却还是老页面
怎么踩的?
前端用了默认打包配置,JS 文件名不变,浏览器命中了强缓存,用户根本没加载到新版资源。
怎么救?
-
打包输出文件名加上 hash,比如:
app.3e9fbd.js
Vite/Webpack 都支持 [contenthash]
。
-
确保 HTML 不缓存!因为 HTML 决定了要加载哪个 JS 文件,如果 HTML 没更新,JS 永远也更新不了。
Cache-Control: no-store
-
如果用了 CDN,还要记得清缓存或者上版本号。
🧨 场景二:接口数据老是卡住,怎么刷新都不变?
怎么踩的?
很多时候是 GET 请求被浏览器或者中间代理缓存了。
比如:
GET /api/user/info
但服务端没写清楚 Cache-Control
,浏览器自动缓存了响应。
怎么救?
-
后端返回头加上:
Cache-Control: no-cache, no-store, must-revalidate
-
前端请求的时候,给 URL 加时间戳,强制打破缓存:
fetch(
/api/user/info?_t=${Date.now()}
)
🧨 场景三:Service Worker 缓了个寂寞,更新根本不生效
怎么踩的?
你可能用了 Workbox 或手写了 SW 缓静态资源,但是没处理好版本更新流程,结果用户永远在旧版本里打转。
怎么救?
-
每次构建产出时更新 SW 文件里的版本号:
const CACHE_NAME = 'my-app-v2.0.1';
-
在
install
阶段调用self.skipWaiting()
,跳过等待状态。 -
在
activate
阶段用clients.claim()
接管所有页面。 -
页面上监听 SW 更新事件,给用户提示"有新版本啦,点我刷新"。
三、前端缓存怎么设计才靠谱?
我们总结一个简化但实用的资源缓存模型:
|--------------|-------------------------|---------------|
| 资源类型 | 缓存策略 | 原因 |
| index.html
| no-store
| 确保每次加载最新入口 |
| JS/CSS(打包产物) | max-age=1y, immutable
| 文件名唯一,放一年都没问题 |
| 图片 / 字体 | CDN 强缓存 | 资源大且变化少 |
| 接口数据 | no-cache
/ 加时间戳 | 实时性要求高 |
| PWA 离线资源 | SW 控制 | 手动缓存 + 可更新 |
四、工程化落地建议
别只靠脑子记,我们得把缓存策略写进构建流程里:
4.1 打包配置文件指纹
Webpack/Vite:
output: {
filename: '[name].[contenthash].js'
}
4.2 HTML 注入正确的资源引用
Webpack 用 HtmlWebpackPlugin
;Vite 自动处理。
4.3 CDN 清缓存脚本
比如:
npx aliyun-cdn-purge path/to/index.html
或者自动脚本 + Git Hook 联动清缓存。
五、Service Worker
建议不要上来就用 SW 缓全站资源,除非你非常清楚它的行为。
常用策略:
- 图片、静态文件:Cache First
- 接口数据:Network First
- HTML 入口:Network Only
- 通知/消息等:Network Only + fallback
搭配 Workbox,配置如下:
workbox.routing.registerRoute(
/\.(?:png|jpg|jpeg|svg)$/,
new workbox.strategies.CacheFirst({
cacheName: 'images',
})
);
更新版本时,只需要更新缓存名,比如:
const CACHE_NAME = 'v2.0.3';
页面监听更新:
navigator.serviceWorker.onupdatefound = () => {
// 显示刷新提示
}
六、调试缓存的几种方法
- Chrome DevTools → Network 里看资源的
Status
是不是(from disk cache)
或(from memory cache)
- 查看
Response Headers
是否有Cache-Control
、ETag
curl -I
直接看 HTTP 响应头- Service Worker 状态 → Chrome DevTools → Application → Service Worker
总结
浏览器缓存细节极多,尤其是前端更新策略和 CDN/服务器协作时,要明确方向:
- 明确哪些资源该缓存、缓存多久
- 更新机制清晰、可控、不怕上线
- 构建流程自动化,不靠人肉维护