闭包在 setinterval 中“看不到”外部变量更新，根本原因是回调函数创建时捕获的是当时作用域中变量的引用或快照值，之后无论该变量如何变化，只要回调没重建，就始终读取最初那一份。
闭包在 setInterval 中“看不到”外部变量更新，根本原因是：回调函数创建时捕获的是当时作用域中变量的引用或快照值，之后无论该变量如何变化，只要回调没重建，它就始终读取最初那一份。
看变量声明方式是否导致共享绑定
用 var 声明的循环变量，在整个函数作用域内共用一个内存地址。所有定时器回调都闭包捕获同一个 i，等异步执行时，i 早已变成终值（如 5）。
- ❌ 错误写法：
for (var i = 0; i console.log(i), 1000); }→ 全部输出5 - ✅ 正确写法：
for (let i = 0; i console.log(i), 1000); }→ 输出0到4，因为每次迭代生成独立绑定
查定时器是否依赖了可变对象的属性
如果 setInterval 回调里直接读取一个对象的字段（如 config.url），而这个对象后续被修改，回调可能拿到新值——这不是“陷阱”，而是你没意识到它本就会实时读取；但若你本意是固定用初始值，这就出错了。
- ❌ 风险写法：
const config = { url: '/api/1' }; setInterval(() => fetch(config.url), 1000); config.url = '/api/2';→ 后续请求可能发到/api/2 - ✅ 安全写法：
const savedUrl = config.url; setInterval(() => fetch(savedUrl), 1000);或使用const声明不可重赋值的配置对象
验 useEffect 或组件内定时器是否漏写了依赖项
在 React 中，useEffect 里启动 setInterval 却把依赖数组写成空数组 []，等于告诉 React：“只运行一次，永远别更新”。此时回调永远闭包捕获首次渲染时的状态值。
- ❌ 典型陷阱：
useEffect(() => { setInterval(() => console.log(count), 1000); }, []);→count永远是 0 - ✅ 改进方向：要么补全依赖（但会频繁重建定时器），要么改用
ref存最新值并在回调中读取，或用函数式更新避免依赖状态
观察定时器是否长期持有大对象引发内存泄漏
如果 setInterval 回调里引用了 DOM 节点、大型数据或组件实例，又没在适当时候清除，这些对象就无法被垃圾回收——闭包成了“隐形锁”。
- ❌ 危险模式：
const timer = setInterval(() => render(canvas, bigData), 1000);且未在组件卸载时clearInterval(timer) - ✅ 必做动作：保存定时器 ID，配合清理函数（
useEffect的返回函数或componentWillUnmount）及时释放；对事件监听同理
