闭包本身不污染变量，但用法不当会导致变量意外共享或长期驻留：①循环中var声明使所有闭包共用同一变量；②跨模块回调捕获过期/共享对象引发脏数据；③闭包延长变量生命周期致内存泄漏；④顶层闭包隐式依赖全局配置造成命名空间污染。
闭包本身不会污染变量，但用法不当会让变量“意外共享”或“不该活却一直活”，表现为值错乱、内存涨得快、组件状态混乱。关键不是闭包有错，而是它把变量锁得太紧、传得太宽、挂得太久。
循环中 var 声明 + 闭包 → 所有回调共用同一个变量
这是最典型也最容易复现的污染场景：循环绑定事件、批量发起请求时，用 var 声明索引或数据，闭包捕获的是变量本身，不是当时的值。
- 错误写法：
for (var i = 0; i console.log(i), 0); }→ 输出全是 3 - 原因：
i是函数作用域，循环结束时值为 3，所有定时器回调都引用这个最终值 - 修正方式：
✅ 改用let（块级绑定，每次迭代生成独立绑定）
✅ 或用 IIFE 封装当前值：(function(idx) { setTimeout(() => console.log(idx), 0); })(i)
✅ React 中批量渲染时，确保事件处理器传入唯一 key 或 id，别依赖循环变量
跨模块回调中闭包捕获过期或共享状态
模块 A 把一个带闭包的函数交给模块 B 执行，如果闭包里直接用了外部对象（如 this.state、config），而该对象后续被修改或销毁，B 执行时拿到的就是脏数据或已释放引用。
- 常见表现：点击按钮后 log 出旧的 userId、弹窗显示上一次的数据、异步回调里
this指向 null - 识别线索：控制台报
Cannot read property 'xxx' of null，或日志显示状态明显滞后 - 修正方式：
✅ 回调创建时只捕获必要字段（如id、name），不传整个对象
✅ 使用useRef在 React 中保存最新值快照，闭包读ref.current而非直接捕获 state
✅ 模块间传递参数时显式解构，避免“传对象→闭包捕获→后续改对象→回调取错值”链路
闭包意外延长局部变量生命周期 → 内存持续增长
变量本该随函数退出而释放，但一旦被闭包持有，又通过全局、事件监听器或定时器长期驻留，就变成“隐性全局变量”。
- 典型错误：
window.handler = () => console.log(hugeData)，其中hugeData是函数内创建的大数组 - 后果：即使函数执行完，
hugeData仍被window.handler强引用，无法 GC - 修正方式：
✅ 避免把闭包赋值给全局对象；必须挂载时，只传必要参数，不闭包大对象
✅ 使用WeakRef包裹非关键引用（现代环境）
✅ 组件卸载或页面跳转前，手动置空：hugeData = null，切断闭包引用链
✅ Chrome DevTools → Memory → Heap Snapshot → 筛选 Closure → 查 Retainers，确认是否指向window或长生命周期对象
模块顶层闭包污染命名空间或配置对象
在模块文件顶部定义函数，内部闭包了 window.config、document.body 或某个单例实例，然后该函数又被导出供多处使用，结果一处修改影响全局行为。
- 例子：
const fetcher = () => api.get('/user', { timeout: window.config.timeout })，若window.config.timeout后续被改，所有调用都受影响 - 风险：看似封装，实则引入隐式依赖；不同模块可能无意覆盖同一全局配置
- 修正方式：
✅ 模块初始化时把所需配置“快照”进闭包：const timeout = window.config.timeout; return () => api.get(..., { timeout })
✅ 用工厂函数隔离上下文：createFetcher({ timeout: 5000 })
✅ 所有模块配置走统一注入机制（如 DI 容器），避免直接读全局
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
