闭包本身不造成内存泄漏，问题在于不该长期持有的引用被意外锁定；应只捕获必要字段、避免持有大对象或DOM节点引用，事件监听需成对管理，定时器须可控可清，缓存推荐WeakMap或带TTL机制。
闭包本身不造成内存泄漏，问题出在“不该长期持有的引用被闭包意外锁住了”。处理的核心不是消灭闭包，而是让闭包只拿它真正需要的、最小的数据，并在不需要时主动松手。
只捕获必要字段，别闭包整个对象
闭包捕获大数组、DOM 节点或组件实例，是最常见的泄漏起点。重点不是变量在哪声明，而是它是否被闭包“拖住”不放。
- 避免：
return () => console.log(largeArray)—— 整个数组被锁死 - 推荐：
const { length, [0]: first } = largeArray; return () => console.log(length, first)—— 只提取用得上的值 - 对 DOM 元素，优先取
id、dataset或文本内容，而非保留节点引用本身
事件监听必须成对管理，别用匿名函数硬绑
每次写 element.addEventListener('click', () => {...}) 都生成新函数，removeEventListener 根本找不到它，等于白清。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用具名函数或稳定引用：定义一次 handler，绑定和解绑用同一个函数地址
- React 中在
useEffect清理函数里调用removeEventListener - 现代方案优先用
AbortController：传{ signal }给监听器，销毁时只需controller.abort()，自动清理所有关联监听
定时器要可追踪、可中断
裸写的 setInterval 一旦启动，就很难知道谁在用、该不该停。组件卸载后它还在跑，闭包里的 this 或状态就永远卡在内存里。
立即学习“Java免费学习笔记（深入）”；
- 别直接写
setInterval(() => this.update(), 1000) - 封装一个可控的定时器工具，返回带
.clear()方法的对象 - 在组件销毁、路由离开或数据流终止时，明确调用清除方法
缓存别靠普通对象硬存，用 WeakMap 或加 TTL
用 const cache = {} 存闭包函数或计算结果，很容易越积越多，又没机制淘汰旧项。
- 若缓存键是对象（如 DOM 节点、类实例），改用
WeakMap—— 键弱引用，对象被 GC 后，对应缓存自动失效 - 若必须用字符串键，给缓存加时间戳和过期检查，或限制最大条目数
- 避免在模块顶层闭包中维护长期存活的 Map/Array，除非你明确控制它的生命周期
