javascript缓存机制本身不导致内存泄漏，但不当使用（如全局缓存、未清理的事件监听器/定时器、闭包隐式持有大对象）会阻止gc回收，引发泄漏；应改用weakmap、限制生命周期、及时解绑、显式释放引用。
JavaScript 缓存机制本身不会直接导致内存泄漏，但不当使用缓存（如全局对象、闭包、事件监听器、定时器等）会阻止垃圾回收器释放不再需要的对象，从而引发内存泄漏。关键在于理解哪些缓存行为容易“意外持引用”，并主动管理生命周期。
避免全局缓存对象长期持有引用
将缓存数据挂载在 window、globalThis 或模块顶层变量上，尤其存储 DOM 节点、大型数组或函数闭包时，极易造成泄漏。这些引用无法被 GC 清理，即使对应页面/组件已卸载。
- 改用弱引用结构：对 DOM 元素缓存优先考虑 WeakMap（键为元素，值为关联数据），它不阻止键对象被回收
- 限制缓存生命周期：为每个缓存项添加时间戳和最大存活时长，定期清理过期项（如 LRU 策略）
- 避免直接缓存整个 Vue/React 组件实例或 React ref.current —— 只缓存必要状态或序列化后的纯数据
及时解绑事件监听器与定时器
缓存中若保存了绑定到 DOM 的事件处理器（尤其是匿名函数），而未在组件销毁或节点移除时移除，就会形成“悬挂引用”。同理，未清除的 setInterval 或 setTimeout 也会持续持有回调函数及其闭包作用域。
- 给事件监听器命名并保留引用，便于后续调用 removeEventListener
- 使用 AbortController 配合 addEventListener 的 signal 选项（现代浏览器支持），统一控制监听器生命周期
- 定时器 ID 存入缓存时，务必在缓存失效或组件卸载时调用 clearTimeout/clearInterval
警惕闭包中隐式缓存大对象
工厂函数或高阶函数返回的闭包常被用于“缓存计算结果”，但如果闭包捕获了外部作用域中的大型对象（如完整响应数据、File 对象、Canvas 上下文），而该闭包又被长期持有（例如赋值给全局变量或缓存 Map），就构成泄漏链。
- 检查闭包依赖：用 Chrome DevTools 的 Memory > Allocation instrumentation on timeline 捕获可疑闭包分配
- 显式释放：在缓存淘汰时，手动将闭包内引用置为 null（尤其对 ArrayBuffer、TypedArray、Blob 等）
- 用 JSON.parse(JSON.stringify()) 或结构化克隆（structuredClone）替代直接引用原始数据，切断引用链
合理使用 WeakRef 和 FinalizationRegistry（谨慎启用）
ES2021 引入的 WeakRef 和 FinalizationRegistry 提供了更细粒度的弱引用控制能力，适用于需要“观察对象是否已被回收”的高级缓存场景（如资源池、对象映射表）。
- WeakRef 允许你持有对象而不阻止其被 GC；每次访问需调用 .deref() 并检查返回值是否为 undefined
- FinalizationRegistry 可注册回调，在对象被回收后执行清理逻辑（如释放 WebAssembly 内存、关闭流）
- 注意：它们不保证立即执行，也不适合做关键业务逻辑，仅作辅助清理手段
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
