JavaScript缓存策略需分层设计：静态资源用Cache-Control+immutable，动态接口用no-cache/ETag，Service Worker实现缓存优先+网络兜底，内存缓存用Map+TTL，localStorage须手动序列化、加过期校验并规避敏感数据。
JavaScript 缓存策略直接决定用户首次加载和后续访问的速度、服务器压力大小，以及离线场景下功能是否可用。没设计缓存，等于让每个用户反复下载同一份 JS 文件、重复执行相同计算、频繁发起无意义请求——性能差、体验卡、成本高。
为什么 Cache-Control 比 Expires 更值得依赖？
因为 Expires 依赖客户端时间，一旦用户设备时间被手动调快/调慢，缓存就可能提前失效或长期不更新；而 Cache-Control: max-age=31536000 是相对时间，由浏览器内部计时器控制，更可靠。
- 静态 JS 文件（如
app.a1b2c3.js）应配Cache-Control: public, max-age=31536000, immutable—— “immutable” 告诉浏览器：这个 URL 永远不会变内容，连协商缓存都跳过 - 动态接口（如
/api/user/profile）别用max-age=3600硬设，应改用no-cache或max-age=60+ETag，否则用户可能看到 1 小时前的旧数据 - 开发时可通过 Chrome DevTools 的 Network 面板 → Header → Response Headers 查看实际生效的缓存头，确认服务端配置已生效
如何用 Service Worker 实现“缓存优先 + 网络兜底”？
这是 PWA 和强离线支持的核心逻辑，不是简单“把文件存下来”，而是精准控制请求生命周期。
- 注册必须在 HTTPS 或
localhost下进行，否则navigator.serviceWorker.register()会静默失败 -
caches.match(event.request)只匹配完全相同的 URL 和请求方式（比如 GET /data.json ≠ POST /data.json），注意 query 参数差异也会导致不命中 - 避免在
install事件里缓存过多资源，否则安装失败会导致 SW 不激活；建议只预缓存核心 JS/CSS/HTML，其余按需缓存
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request).then(cached => {
if (cached) return cached;
return fetch(event.request).catch(() => caches.match('/offline.html'));
})
);
});内存缓存用 Map 还是普通对象？什么时候该加 TTL？
用 Map。普通对象把对象/数组当 key 会变成 "[object Object]"，彻底失效；Map 支持任意类型作 key，且可迭代、可精确清理。
立即学习“Java免费学习笔记（深入）”；
- 高频函数结果（如表单校验、坐标转换）适合用
Map+JSON.stringify(args)生成 key - API 响应缓存必须加 TTL，否则页面长期运行后内存持续增长；推荐写法：
cache.set(key, { data, expires: Date.now() + 5 * 60 * 1000 })，读取前检查expires - 别用
setTimeout给每个缓存项单独设定时器——成百上千个定时器会拖垮主线程；改用惰性清理：读取时判断过期，写入时定期遍历清理
localStorage 存 JS 数据时最常踩的三个坑
localStorage 看似简单，但用错就成性能毒药或数据黑洞。
- 它只能存字符串，
localStorage.setItem('user', {name: 'Alice'})实际存的是"[object Object]"—— 必须手动JSON.stringify和JSON.parse - 没有自动过期机制，缓存旧数据比不缓存更危险；务必自己加
expires字段，并在读取时校验 - 写入大体积数据（如上 MB 的日志）会阻塞主线程，且多数浏览器限制为 5–10MB；超过后
setItem抛QuotaExceededError，需 try/catch
真正难的不是“怎么存”，而是“什么时候不该存”——比如用户 token 绝对不该进 localStorage，敏感操作后的缓存必须同步清除，还有跨标签页时 storage 事件监听漏掉导致状态不一致……这些细节不处理，缓存反而成为 bug 温床。
