回调函数本身不导致内存存留，问题出在它作为闭包被长期持有且捕获了不该长期存在的变量；常见宿主包括dom元素、全局定时器、事件总线、websocket等，需通过chrome memory面板比对快照、查看retainers定位并及时解绑。
回调函数本身不导致内存存留，问题出在它作为闭包被长期持有，且捕获了不该长期存在的变量。
回调是闭包的常见载体
大多数回调（事件监听、定时器、Promise.then、fetch回调等）都是函数表达式或箭头函数，定义在某个作用域内并引用了外部变量——这天然构成闭包。只要这个回调还被 JS 引擎“看得见”，它捕获的整个外层作用域就无法释放。
- 比如
element.addEventListener('click', () => console.log(data))：data是大型对象，回调一绑定，data就被锁住 -
setTimeout(() => doSomething(this.state), 5000)：若组件已卸载，this.state仍被持有，无法 GC -
fetch('/api').then(res => updateUI(res, config))：若config是大配置对象，且请求慢、页面早跳走，它就白占内存
真正让内存“卡住”的是持有关系
回调函数一旦被注册到某个长期存活的宿主上，就等于给它发了“长期居留许可”。常见宿主包括：
- DOM 元素（
addEventListener后未removeEventListener） - 全局定时器（
setIntervalID 未clearInterval） - 第三方库的事件总线、状态管理器、缓存 Map 或 window 属性
- 未销毁的 WebSocket、Observer、IntersectionObserver 实例
这些宿主不死，回调不被移除，它捕获的 data、this、props、refs 就全得原地待命。
典型泄漏写法与安全替代
不是不能用回调，而是要控制它的生命周期和捕获范围：
- 避免在回调里直接访问大对象：改传
id或轻量字段，后续按需查表 - 用
AbortController.signal配合addEventListener或fetch，中断后自动解绑 - React 中在
useEffect清理函数里清除定时器、监听器；Vue 中用onBeforeUnmount - 原生 JS 可封装统一清理机制，例如维护
const listeners = []，批量removeEventListener - 对必须缓存的回调，用
WeakMap关联 DOM 节点，节点销毁时缓存自动失效
怎么确认是回调引起的存留？
打开 Chrome DevTools → Memory 面板 → 拍 Heap Snapshot：
- 搜索
(closure)，看哪些闭包 Retained Size 异常高 - 点开闭包，看 “Retainers” 列表：是不是被
Window、Timer、EventListener或某个 Map 持有 - 对比操作前后的快照，筛选增长明显的
Closure类型，顺藤摸瓜定位注册位置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
