闭包本身不导致内存泄漏，但定时器中闭包捕获大对象（如dom节点、大型数组）且未清除定时器时，会因强引用阻止垃圾回收；应通过参数传参、解构提取、及时cleartimeout/clearinterval及调度优化来防范。
定时器处理函数中用闭包捕获变量，本身不必然导致内存问题，但若设计不当，容易让本该释放的变量长期滞留堆中。关键不在“用了闭包”，而在于“捕获了什么”和“保留了多久”。
闭包如何让变量无法被回收
当 setTimeout 或 setInterval 的回调函数引用了外层作用域的变量（比如一个大数组、DOM 节点或配置对象），V8 会把该变量提升到堆内存，并通过回调函数的 [[Environment]] 持有其引用。只要这个回调函数还存在（例如被挂到全局、未清除的定时器、事件监听器），变量就无法被垃圾回收。
- 哪怕只捕获一个数字，引擎也可能连带保留整个词法环境中的其他未使用变量（尤其在 var 声明 + 旧写法下）
- 使用 let 声明循环变量可让每次迭代生成独立绑定，缩小闭包实际持有的变量范围
- 返回的闭包若赋值给长生命周期对象（如 window.xxx、组件实例属性），等于人为延长所有被捕获变量的存活时间
哪些变量最容易引发内存压耗
不是所有被捕获的值都危险，真正拖慢 GC、推高内存的是那些体积大、生命周期本该短暂，却被闭包意外“锁住”的对象：
- 大型数据结构：如缓存 Map、用户列表数组、未压缩的 base64 图片字符串
- 强引用 DOM 元素：闭包中持有已从页面移除但仍被引用的节点，阻止整棵子树回收
- 资源型对象：数据库连接、WebSocket 实例、未释放的 Canvas 上下文
- 未清理的定时器句柄：setInterval 回调持续运行，且内部闭包又反向引用了外部大对象
轻量闭包的实践方式
目标是让闭包只携带执行必需的最小信息，其余交由外部统一管理：
- 用 setTimeout(cb, delay, ...args) 的参数传参机制替代闭包捕获，避免形成对外层作用域的依赖
- 提前解构提取必要字段，例如 const { id, timeout } = config，再让回调只引用 id 和 timeout，不碰 config.data
- 对需复用的资源（HTTP client、缓存池），由外部单例或 WeakMap 管理，闭包内只调用 getSharedClient()，不直接持有实例
- 任务执行完毕后主动切断引用，如将 taskRef = null、cacheHolder = undefined
海量定时器场景下的调度优化
单个闭包轻量还不够，面对数万任务，更应从调度结构上降压：
- 禁用每个任务配一个 setTimeout，改用时间轮（HashedWheelTimer）或分片队列，所有任务共享一个驱动线程
- 闭包仅用于封装“触发时要做什么”，不包含初始化逻辑、重试策略或状态机——这些抽离为独立模块按需调用
- 支持任务过期自动卸载：调度器在分发前检查任务状态，已取消/超时的任务跳过执行并清空其闭包引用
- 冷加载策略：初始只注册首屏或高频任务，其余按需延迟实例化闭包，避免启动时内存峰值
