最简单的内存缓存是用普通 JavaScript 对象（{}）作键值容器，适合单页应用临时存储；应封装为支持过期、LRU淘汰和自定义TTL的类，优先用Map；需分层结合Service Worker、HTTP缓存和localStorage，并按业务场景设计失效策略。
用内存对象实现基础缓存
最简单的缓存就是用一个普通 JavaScript 对象（{}）当作键值存储容器。适合单页应用中临时保存 API 响应、计算结果或 DOM 元素引用。
- 写入时：用唯一 key（如 URL + 参数序列化）作为属性名，存入数据和时间戳
- 读取时：先检查 key 是否存在，再判断是否过期（比如当前时间 - 存储时间 > 有效时长）
- 示例：cache['/api/user?id=123'] = { data: {...}, timestamp: Date.now(), ttl: 60000 };
封装可配置的缓存类
手动管理对象容易混乱，建议封装成带过期、容量限制和淘汰策略的类。关键能力包括：自动清理过期项
、LRU（最近最少使用）淘汰、支持自定义 TTL。
- 用 Map 替代普通对象，便于按插入顺序管理、快速删除首尾项
- 读取时把对应项移到末尾（模拟“最近使用”），写入超限时删掉第一个（最久未用）
- 定时器不是必须的——可在 get/set 时惰性检查过期，避免后台任务开销
结合浏览器能力分层缓存
真实项目不应只靠内存缓存。合理组合多种机制才能兼顾性能与一致性：
-
Service Worker：拦截网络请求，优先返回 Cache Storage 中的响应（适合静态资源或离线兜底）
-
HTTP 缓存头（如 Cache-Control: max-age=3600）：由浏览器自动处理，服务端控制粒度最细
-
localStorage/sessionStorage：持久化少量结构化数据（注意大小限制和同源限制）
- 内存缓存放在最上层，作为高频访问的“热区”，不替代 HTTP 或磁盘缓存
缓存失效与更新策略要匹配业务场景
缓存最大的风险不是不快，而是不一致。失效逻辑必须和数据变更节奏对齐：
- 读多写少（如商品详情）：设置固定 TTL，容忍短时间旧数据
- 强一致性要求（如用户余额）：写操作后立即 delete cache[key]，下次读触发回源
- 批量更新（如后台发布文章）：可清空相关前缀（Object.keys(cache).filter(k => k.startsWith('/api/posts'))）
- 避免“缓存雪崩”：给 TTL 加随机偏移（如 Math.random() * 5000），防止大量缓存同时过期
、LRU（最近最少使用）淘汰、支持自定义 TTL。