防止函数缓存导致内存无限增长，核心是主动控制缓存的“容量”和“寿命”，需结合lru淘汰、ttl时效、键生成优化及手动清理机制。
防止函数缓存导致内存无限增长，核心是主动控制缓存的“容量”和“寿命”，不能只存不删。关键不在要不要缓存，而在于怎么让它聪明地存、适时地丢。
限制缓存最大数量，用 LRU 策略自动淘汰
无上限的 Map 或对象缓存，会随调用次数线性膨胀，尤其在参数组合多、生命周期长的场景下极易吃光内存。LRU（最近最少使用）是最实用的淘汰机制：保留最新/最常访问的条目，移除沉寂最久的。
- 手写简易 LRU：用
Map实现（它保持插入顺序），每次 get/set 后把对应项移到末尾；当 size 超限时，删除Map.keys().next().value（即第一个插入的键） - 推荐直接用成熟库，如
lru-cache（Node.js）或轻量版quick-lru（浏览器），它们已处理边界情况（如并发读写、键冲突） - 设定合理容量阈值：例如 API 请求结果缓存设为 100 条，组件计算结果设为 20 条——根据实际调用频次和数据大小动态调整，而非拍脑袋定 1000
给缓存加有效期，避免“脏数据”长期驻留
有些结果天然有时效性（如用户权限、实时价格、临时 token），缓存再省资源，返回过期结果就是业务错误。单纯靠 LRU 不解决时间维度的问题。
- 为每条缓存记录附加时间戳，在 get 前检查是否超时，超时则丢弃并重新计算
- 可封装成带 TTL 的缓存工厂：
createMemoizedFn(fn, { maxAge: 5 * 60 * 1000 }) - 注意：不要用
setTimeout为每个缓存项单独设定时器——会产生大量 timer，加剧内存与 GC 压力；统一轮询或惰性检测更稳妥
避免缓存引用类型参数引发的“假命中”
用 JSON.stringify(args) 生成键看似方便，但对象/数组内容变了，序列化结果却可能一样（比如属性顺序不同、含 undefined 或函数），或者相同内容被多次序列化产生不同键，导致缓存失效或冗余堆积。
- 对简单参数（数字、字符串、布尔）直接拼接键，如
`${a}-${b}` - 对对象参数，优先提取稳定字段做键，例如
user.id或api.url + JSON.stringify(params)，而非整个对象深串化 - 若必须深比较，用结构化克隆或专用工具（如
fast-deep-equal）预处理，而不是反复序列化——减少 CPU 和内存开销
提供手动清理入口，配合业务生命周期
自动策略管不住所有场景。比如用户登出后，应清空其个人数据相关缓存；表单重置时，清除依赖当前输入的计算结果。
- 在 memoized 函数上暴露
.clear()方法，内部清空 Map 或重置 cache 对象 - 支持按 key 清理：
.delete(key)，便于局部刷新 - 在 React/Vue 等框架中，把缓存实例绑定到组件实例或 store 模块里，卸载时自动调用 clear，避免闭包持有导致内存泄漏
不复杂但容易忽略：缓存不是加了就完事，它本身就是一个需要被管理的状态。设计之初就想好谁来删、什么时候删、删多少，才能真正兼顾性能与健壮性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
