局部变量被全局监听器意外持有是前端内存假死主因；Chrome Heap Snapshot中Retainers路径以(global)→window→…开头即表明对象被window强引用，常见于未清理的匿名事件监听器闭包捕获整个作用域。
局部变量被意外“钉”在全局监听器里，是前端内存假死最隐蔽也最常见的原因。它不表现为明显泄漏（比如对象持续增长），而是让组件、状态、dom 节点全部滞留，页面交互变卡、gc 无效、内存居高不下——看起来像卡死，实则是 gc 无法回收。
看 Retainers 链路，找“(global)→ window → …”这个关键信号
在 Chrome Heap Snapshot 的 Retainers 面板中，定位到疑似滞留的对象（比如某个组件实例、ref、大型数组），右键 → Reveal in Summary view，再点进它的 Retainers 树：
- 如果路径以 (global)→ window → … 开头，说明该对象正被 window 全局强引用着
- 重点不是“它在哪”，而是“谁在 window 上挂了它”：常见是
window.addEventListener('resize', () => {...})这类匿名监听器 - 若路径中出现
_events、listener、eventHandlers等字段，基本可锁定是事件系统在持有着闭包环境 - 路径终点若为
window.myHandler或window.__temp，说明代码里显式赋值过，要反查源码定位赋值点
识别闭包隐式捕获：一个匿名函数拖垮整个组件
匿名监听器本身没名字，removeEventListener 无法精准移除；更危险的是，它会把外层所有变量打包进闭包——哪怕只是 const api = useApi()，整个 hook 实例、内部缓存、甚至父组件的 props 和 ref 都会被拖住。
- Retainers 深度常达 8–12 层，但真正要删的，往往只是那一行
addEventListener('scroll', () => {}) - 典型症状：组件已卸载（
onUnmounted或useEffect cleanup已执行），但快照里仍能看到完整组件树和响应式数据 - Vue 中尤其要注意
onMounted里直接写setInterval或addEventListener，未配对清理就会导致整个setup作用域被锁死
快速验证与修复路径
不用等用户反馈或线上报警，本地就能复现并验证：
- 在目标页面打开 DevTools → Memory 面板 → 拍摄 Heap Snapshot，操作一次关键交互（如打开弹窗、切换 tab），再拍一张，用 Comparison 查看新增对象，筛选
Detached或构造函数名匹配的组件 - 对可疑对象点开 Retainers，逐层往上点，直到看到
window或document—— 停在这里，就是泄漏源头 - 修复时统一改用具名函数或
useCallback绑定：const handleScroll = useCallback(() => {}, [deps])，确保 cleanup 里能传入完全相同的引用 - React 中必须在
useEffect返回函数里调用removeEventListener；Vue 中对应onBeforeUnmount或onUnmounted；小程序中务必在onUnload里清理
绕过“假死”的临时观测技巧
当页面已卡顿、DevTools 无法响应时，可用轻量方式辅助判断：
- 在控制台运行
performance.memory，观察usedJSHeapSize是否持续上涨且不回落 - 执行
getEventListeners(window)，检查是否有大量未清理的匿名函数监听器（输出里显示function () { ... }就是风险信号） - 手动触发 GC（Memory 面板点击垃圾箱图标），若之后内存无明显下降，说明有强引用阻止回收，大概率就是全局监听器+闭包问题
