本质是局部变量被意外延长生命周期，陷入全局单例+事件监听器+闭包捕获的三角陷阱，导致gc无法回收而引发隐式内存假死。
这类问题本质是“局部变量被意外延长生命周期”，最终卡在全局单例+事件监听器+闭包捕获的三角陷阱里。真正卡住系统的不是内存爆满，而是大量本该释放的对象被 window 或单例实例死死拽住，GC 无法回收，表现为响应变慢、定时器延迟、UI 卡顿——即所谓“隐式内存假死”。
看堆快照中是否出现“(global)→window→…”或“(global)→Singleton→…”链路
打开 Chrome 或 DevTools 的 Memory 面板，拍一个 Heap Snapshot，筛选疑似泄漏对象（如大量重复的组件实例、API 实例、Ref 对象），右键 → Reveal in Summary view，再切换到 Retainers 标签页：
- 若路径以 (global)→window→… 开头，说明它被挂到了全局作用域，比如
window.resizeHandler = () => {...}或未清理的window.addEventListener('resize', handler) - 若路径是 (global)→MyUtils→…（MyUtils 是你写的全局单例类），说明单例内部持有引用，而该引用又捕获了不该捕获的局部变量（例如某次页面加载时传入的
props、ref、useState返回值） - 重点留意路径中是否含
_events、listeners、handlers、callback等字样——这基本锁定是事件系统在维持强引用
检查单例类中是否用匿名函数注册监听器
匿名函数无法被 removeEventListener 精确移除，且会隐式捕获整个词法环境。例如：
- ❌ 错误写法：
MyUtils.on('data', (v) => this.update(v))—— 每次调用都生成新函数，旧监听器永远残留 - ❌ 更危险写法：
MyUtils.on('scroll', () => setState(...))—— 直接捕获 React 组件的 state、props、ref，整棵组件树被钉死 - ✅ 正确做法：把监听器声明为类字段或模块级具名函数，确保复用同一引用；在单例销毁或组件卸载时，显式调用
off或removeEventListener
验证单例是否具备明确的销毁/重置机制
全局单例不能只管“创建”，必须管“清理”。尤其在 SPA 多页/多 Tab 场景下，单例可能长期存活，但其内部监听的上下文（如某个已卸载页面的 DOM 节点、已 unmount 组件的 ref）却早已失效：
- 检查单例是否有
destroy()、clearListeners()或reset()方法，并确认它被真实调用（例如在路由离开、应用登出、窗口关闭时） - 单例内部建议用 WeakMap 存储“临时绑定关系”，避免强引用 DOM 元素或组件实例；对非必要缓存（如请求结果、计算中间值）设置 TTL 或按需清空
- 在 HarmonyOS 或 ArkTS 环境中，特别注意
UIAbility生命周期与单例初始化/销毁时机是否错位——例如在onDestroy中未调用单例清理，会导致后续冷启动仍复用脏状态
用代码契约约束监听器注册行为
靠人肉审查容易遗漏，建议从工程层面加固：
- 在单例的
on()方法中加入调试断言：当检测到传入的是箭头函数或无 name 的函数时，开发环境下抛 warning（fn.name === ''） - 封装统一的事件注册 Hook（如
useGlobalListener(type, handler, deps)），内部自动管理on/off配对，并绑定 useEffect cleanup - 对关键单例（如网络工具、主题管理器）添加单元测试，模拟多次 init → destroy → init，验证监听器数量不递增、内部缓存可清空
