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