闭包引用 dom 元素未清理导致内存泄漏：事件监听器中闭包捕获 dom 节点且未移除时，即使节点已从 dom 移除，仍被强引用而无法 gc；应使用 removeeventlistener 或 abortcontroller 显式清除。
闭包引用 DOM 元素后未清理
最典型的泄漏场景是：事件监听器里用了闭包，闭包又捕获了某个 DOM 节点（比如 container），而监听器没被移除，节点就无法被 GC。哪怕父容器已从 DOM 中 remove()，只要监听器还活着，整个子树就被闭包强引用着。
- 检查是否在
addEventListener回调中直接访问了外部节点变量，尤其是通过document.getElementById或querySelector获取后又长期持有 - 用 Chrome DevTools 的
Memory面板录制堆快照，筛选Detached DOM tree，再点开看 retainers，如果看到Closure→function→DOM element链路，基本就是它 - 修复方式不是“不用闭包”，而是确保监听器能被显式清除：用
removeEventListener配合具名函数，或用AbortController（现代写法）
setTimeout / setInterval 中闭包持有大对象
定时器回调形成的闭包，容易无意中捕获整个组件实例、大型数据结构甚至 WebSocket 实例。只要定时器没被 clearTimeout 或 clearInterval，闭包就一直活，连带所有被捕获的值。
- 特别注意 React 类组件中
componentDidMount启动的定时器，若没在componentWillUnmount清理，this.state和this.props就持续驻留 - 避免在定时器回调里直接读取
this或外部作用域的大数组/对象；改用参数传入必要字段，或用useRef存状态快照 - 用
WeakMap缓存依赖项时要小心——它不阻止 GC，但若你用它缓存了本该被释放的对象，反而会干扰判断
闭包中意外保留对全局对象的引用
比如在模块顶层定义一个函数，内部闭包引用了 window、document 或某个全局配置对象，而这个函数又被挂到某个长生命周期对象上（如 EventTarget 实例、自定义 emitter），就会让全局对象上的属性无法释放。
- 典型错误：
const handler = () => console.log(window.someBigConfig)，然后emitter.on('data', handler)，但忘了off - 用
console.memory观察jsHeapSizeLimit和totalJSHeapSize是否随操作持续上涨，配合performance.memory（需开启--enable-precise-memory-info）辅助定位 - 优先使用局部变量 + 显式传参代替隐式捕获；对必须捕获的全局对象，考虑用
WeakRef包一层（仅限现代环境），或手动置null切断引用
React 函数组件中 useEffect 闭包陷阱
Hook 的依赖数组机制本身是防泄漏的设计，但开发者常误写依赖项，导致旧闭包持续执行，同时捕获过期的 props/state —— 这些过期值背后可能连着未卸载的组件实例。
- 常见错误：依赖数组漏写
someCallback，导致useEffect里调用的仍是首次渲染时的闭包，里面props.data是旧引用，而新data又被其他地方引用，旧数据卡在内存里出不去 - 用 ESLint 插件
eslint-plugin-react-hooks强制校验依赖项，比肉眼检查可靠得多 - 对需要稳定引用的函数，用
useCallback包裹并正确声明依赖；但别为了“避免重定义”而把整个对象塞进依赖数组，应拆解为原子字段
Detached DOM tree 和 Closure 的 retainers 链路是最直接线索，但真正难的是确认“哪个闭包本该结束却没结束”。多数时候问题不在闭包本身，而在生命周期管理缺失——比如忘记取消网络请求、没清理定时器、或事件监听器注册后永远不注销。
