JavaScript缓存策略需主动设计，分内存缓存（Map/对象）、持久化缓存（localStorage/IndexedDB）和请求级缓存（HTTP头+Service Worker），核心是明确存取时机、内容与失效机制。
JavaScript 中的缓存策略不是浏览器自动帮你做的“黑盒”，而是你主动设计的数据暂存逻辑，核心目标是：减少重复计算、降低请求开销、提升响应速度。关键不在“有没有缓存”，而在“什么时候存、存什么、怎么取、何时失效”。
内存缓存：用对象或 Map 快速暂存计算结果
适合纯前端、不跨页面、生命周期短的场景，比如函数结果缓存（memoization）或组件内状态复用。
- 用普通对象做键值对缓存时，注意对象/数组不能直接当 key（会转成 "[object Object]"），改用 JSON.stringify 或生成唯一字符串标识
- 更推荐用 Map，支持任意类型作 key，且可精确控制大小和清理时机
- 简单示例：防抖 + 缓存的 fetch 封装
async function cachedFetch(url) {
const key = `fetch:${url}`;
if (cache.has(key)) return cache.get(key);
const res = await fetch(url);
const data = await res.json();
cache.set(key, data);
return data;
}
持久化缓存：localStorage / sessionStorage / IndexedDB 按需选型
需要跨刷新保留数据时使用，但要注意容量限制、序列化成本和过期管理。
- localStorage：5MB 左右，同步读写，适合小量结构化数据（如用户偏好、API 响应快照），记得手动加过期时间字段
- sessionStorage：仅当前标签页有效，适合临时表单草稿、导航状态
- IndexedDB：支持大量结构化数据、事务、索引，适合离线应用（如 PWA），但 API 较复杂，建议用封装库如 idb
请求级缓存：善用 HTTP 头 + Service Worker 精细控制
这是最接近“真实缓存”的层级，依赖浏览器原生机制，但需前后端协同。
立即学习“Java免费学习笔记（深入）”；
- 后端设置 Cache-Control（如 public, max-age=3600）、ETag 或 Last-Modified，前端 fetch 默认就会遵守
- 需要绕过强缓存？加时间戳参数或设置 cache: 'no-cache' 或 'reload'
- 想实现“网络优先+缓存降级”？用 Service Worker 拦截 fetch 请求，先尝试网络，失败再读 cache，或反过来
缓存失效与清理：别让旧数据变成 bug 源头
缓存最大的风险不是没缓存，而是缓存了不该缓存的旧数据。
- 给缓存项加时间戳或版本号，读取前校验是否过期（例如 localStorage 里存 {data: ..., expires: Date.now() + 5 * 60 * 1000}）
- 关键操作后主动清除相关缓存（如用户修改资料 → 清除 profile 缓存）
- 避免全局无脑清空，按 key 前缀或业务域分组管理（如用 "api:user:" + userId 作 key）
基本上就这些。缓存不是加得越多越好，而是每次加之前问一句：它会不会变？变了我知不知道？知道了能不能及时删？设计清楚这三点，缓存就从隐患变成利器。
