settimeout本身不构成循环引用，但用法不当会引发隐性内存泄漏；字符串调用、未保存id的setinterval、回调访问已卸载上下文是三大隐患；需通过封装自动清理定时器、绑定存活状态、weakmap关联宿主等方式从架构层面防护。
setTimeout本身不构成循环引用，但用法不当会引发隐性内存泄漏
setTimeout不会自动创建循环引用，但它常成为“泄漏放大器”——当回调函数捕获了本该释放的外部变量，而定时器又没被清除时，这些变量就被长期持有。关键不在setTimeout语法本身，而在回调作用域的生命周期管理。
最容易踩坑的三种 setTimeout 使用模式
以下写法看似简洁，实则埋下泄漏隐患：
- 字符串形式调用：setTimeout("doSomething()", 1000) —— 会触发全局 eval，可能意外创建全局变量或闭包，已被现代标准弃用
- 未保存 ID 的 setInterval：setInterval(() => updateUI(data), 2000)，却没把返回值存下来，导致无法在组件销毁时清理
- 回调中直接访问已卸载上下文：比如 React 组件里启动定时器，回调里直接 this.setState 或访问 ref.current，而组件早已 unmount
架构级防护：从设计源头切断泄漏链
靠人工 remember to clear 不可靠，需在框架或模块层面建立约束机制：
- 封装带自动清理的定时器工厂：返回 { start, stop } 对象，stop 内部自动调用 clearInterval/clearTimeout，并置空内部引用
- 绑定上下文存活状态：在定时器回调开头加 guard 判断，如 if (!isMounted?.()) return；Vue 可用 onBeforeUnmount，React 推荐 useRef + useEffect 清理函数组合
- 用 WeakMap 关联定时器与宿主对象：例如 const timerRegistry = new WeakMap(); timerRegistry.set(component, timerId)，组件销毁时 WeakMap 自动丢弃键值对，辅助清理逻辑更安全
调试与验证：确认泄漏是否真正消除
不能只看代码写了 clear，要验证运行时行为：
- Chrome DevTools → Memory 面板 → 拍摄堆快照（Heap Snapshot），筛选 constructor 为 Closure，查看是否仍有大量未释放的定时器回调闭包
- Performance 面板录制一段时间，观察 JS Heap 曲线是否平稳，若持续爬升且页面静止，大概率存在未清理的定时器或监听器
- 关闭所有 console.log 后重测——开发中 console.log(obj) 会强持对象引用，掩盖真实泄漏点
