定时器回调执行完毕后不会立即被垃圾回收，其回收取决于是否还存在其他引用；无额外引用时会在下一次gc周期清理，若被闭包、全局变量等持有则持续驻留内存。
JavaScript 中定时器回调执行完毕后，是否立即被垃圾回收，取决于该回调函数是否还存在其他引用。没有额外引用时，它会在下一次垃圾回收周期中被清理；但若被闭包、全局变量或其他对象持有，则会持续驻留内存。
回调函数本身能否被回收？
定时器回调（如 setTimeout 或 setInterval 传入的函数）本质上是一个普通函数值。一旦定时器触发并执行完毕，如果该函数未被任何活动对象引用，就符合垃圾回收条件。
- 匿名函数（如
setTimeout(() => {}, 1000)）通常执行完即失去引用，可被回收 - 命名函数或变量引用的函数（如
const cb = () => {}; setTimeout(cb, 1000)），只要cb变量仍存活，函数就不会被回收 - 若回调内部创建了闭包并捕获了外部变量，那些变量也会因引用链而延迟回收
定时器句柄对内存的影响
定时器返回的 ID（如 setTimeout 返回的数字）只是调度标识，不持有回调引用。但未清除的重复定时器（尤其是 setInterval）可能持续触发回调，间接维持其引用关系。
-
clearTimeout/clearInterval不影响已执行回调的生命周期，只取消未来调用 - 忘记清除重复定时器，可能导致回调反复执行，同时延长相关闭包变量的存活时间
- 定时器 ID 本身是原始值（number），不参与对象级垃圾回收
常见导致内存泄漏的场景
真正阻碍回调及关联数据回收的，往往是开发者无意中建立的强引用，而非定时器机制本身。
- 回调中保存了对大型 DOM 元素、数组或对象的引用，且未在执行后释放
- 将回调赋值给全局属性（如
window.myCallback = () => {...}），造成永久引用 - 在类方法中使用箭头函数作为定时器回调，隐式绑定
this，使整个实例无法回收 - 多个定时器共用同一回调，而该回调又依赖外部作用域变量，扩大了引用范围
如何协助及时回收？
无需手动触发 GC，但可通过减少不必要的引用，让引擎更早判定对象可回收。
- 避免在回调中长期持有大对象；必要时主动置空引用（如
someData = null） - 使用
WeakMap或WeakRef（ES2021）管理关联数据，不阻止目标回收 - 在组件卸载或对象销毁时，显式清除定时器，并解除事件监听等副作用
- 借助 Chrome DevTools 的 Memory 面板录制堆快照，比对前后差异，定位残留回调或闭包
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
