Vue3 组合式函数的内存泄漏排查与预防范式一、组合式函数中的资源生命周期Vue3 的组合式函数Composables让逻辑复用变得简洁但也把资源管理的责任从 Options API 中显式的生命周期钩子转移到了闭包作用域中。一个 Composable 内部可能创建 DOM 事件监听、定时器、WebSocket 连接、IntersectionObserver 实例——这些资源不会因为组件卸载而自动释放除非你显式地在onUnmounted中清理。sequenceDiagram participant C as 组件实例 participant M as Composable 函数 participant R as 外部资源 participant D as DOM / Observer C-M: setup() 调用 Composable M-R: 创建 WebSocket / 定时器 M-D: addEventListener / observe C--M: 组件卸载 Note over M: 未注册清理逻辑 R--M: 连接持续存在内存泄漏 D--M: 事件回调持有效内存泄漏 Note over C,R,D: 泄漏的资源无法被 GC 回收排查时有两个关键现象Chrome DevTools Performance Monitor 中 JS Heap 在组件切换后不降反升Memory 面板的 Heap Snapshot 中 Detached DOM 节点持续累积。二、四种高频泄漏场景场景一事件监听未解绑。在 Composable 中给window、document或某个 DOM 引用添加了事件监听但未在组件卸载时移除。场景二外部数据订阅未取消。使用watch或手动创建的effectScope对全局 store 进行了订阅Composable 实例销毁后订阅仍然存活。场景三异步操作未竞态处理。setTimeout或异步请求的回调在组件卸载后才执行尝试更新已销毁的响应式状态。场景四第三方实例未销毁。echarts.init()、new IntersectionObserver()等第三方库创建的实例未调用对应的销毁方法。三、预防范式统一清理模式推荐的预防范式基于 Vue3 的effectScope将所有副作用收敛到一个作用域中组件卸载时一次性释放import { ref, watch, onUnmounted, effectScope, EffectScope, } from vue; /** * 使用 effectScope 统一管理 Composable 内的所有副作用 * 组件卸载时自动清理避免资源泄漏 */ export function useAutoDisposeT( setupFn: (scope: EffectScope) T ): T { const scope effectScope(); const result scope.run(() setupFn(scope))!; onUnmounted(() { scope.stop(); // 释放该 scope 内的所有 watch / computed / 事件监听 }); return result; } // 使用示例WebSocket Composable export function useWebSocket(url: string) { return useAutoDispose((scope) { const message refstring | null(null); const status refconnecting | open | closed(connecting); let ws: WebSocket | null null; function connect() { ws new WebSocket(url); ws.onopen () { status.value open; }; ws.onmessage (event) { message.value event.data; }; ws.onerror () { status.value closed; }; ws.onclose () { status.value closed; }; } function disconnect() { if (ws) { ws.onopen null; ws.onmessage null; ws.onerror null; ws.onclose null; ws.close(); ws null; } } connect(); // scope.stop() 时自动调用此回调 return { message, status, disconnect }; }); }effectScope的核心价值在于它追踪了其作用域内创建的所有watch、computed、watchEffect等响应式副作用。调用scope.stop()会递归停止所有子作用域释放响应式依赖。四、排查工具与自动化检测Chrome DevTools 提供了一套内存泄漏排查工作流1. Performance Monitor → 观察 JS Heap 趋势组件切换后应回落 2. Memory → Heap Snapshot → 两次快照之间对比 Detached 节点增量和闭包引用 3. Performance → Record → 观察 GC 是否正常回收Major GC 后堆应显著下降工程化检测可以在单元测试中实现内存泄漏断言。使用vi.runAllTimers()和手动触发 GC 来验证 Composable 的清理行为import { describe, it, expect, vi } from vitest; import { useWebSocket } from ./useWebSocket; describe(useWebSocket 内存清理, () { it(组件卸载后应当释放 WebSocket 连接, () { // 使用 process 全局对象避免 TS 类型报错 const originalGc (globalThis as Recordstring, unknown).gc; // 模拟 WebSocket const mockClose vi.fn(); (globalThis as Recordstring, unknown).WebSocket vi.fn(() ({ close: mockClose, addEventListener: vi.fn(), })); // 创建并销毁 Composable此处省略完整 setup 流程 // …… // 触发强制 GC需 node --expose-gc 启动 if (typeof (globalThis as Recordstring, unknown).gc function) { ((globalThis as Recordstring, unknown).gc as () void)(); } expect(mockClose).toHaveBeenCalled(); }); });在生产环境中可以添加一个简单的指标收集监控全局setInterval/setTimeout的数量是否在页面切换后回归基线异常增长直接触发告警。五、总结Composable 的内存泄漏本质上是资源创建的职责与释放的职责分离了。解决问题的关键在于让这两者重新收敛要么使用effectScope将创建与销毁绑定在一起要么在每个 Composable 的内部显式注册onUnmounted清理逻辑。排查优先关注事件监听、外部订阅和第三方实例三种类型的资源它们是泄漏的最高发区。