现代V8引擎能正确回收A↔B循环引用，真正导致内存泄漏的是外部强引用锚点；排查需用Chrome堆快照Comparison模式分析Retainers路径，重点检查window、DOM、定时器、响应式对象等四类高危场景，并在卸载时主动解绑。
循环引用本身在现代 V8 引擎中不会直接导致内存泄漏，因为 GC 使用的是标记-清除算法，能正确处理 A↔B 这类闭环。真正造成泄漏的，是循环中混入了外部强引用锚点——比如全局对象、DOM 节点、定时器、事件监听器或未清理的响应式状态。排查关键不是找“谁引用了谁”，而是定位“谁把这组对象死死拽住不让 GC 松手”。
用堆快照 Retainers 锁定真实持有者
打开 Chrome DevTools → Memory 面板 → 拍摄两次堆快照（操作前空闲态 + 操作后强制 GC 后），切换 Comparison 模式。筛选出 # New > 0 的组件或构造函数，点击任一实例，在右侧 “Retainers” 栏中重点看路径顶端：
- 如果路径以 window、appStore、EventBus 开头 → 检查是否把组件方法注册到全局总线但没 off
- 如果出现 el.__vue__ → component → $parent → children → component → 是 DOM 元素反向持有组件，且组件卸载后未清 el.__vue__
- 如果路径含 setTimeout / setInterval → closure → this → 定时器闭包捕获了组件实例，销毁时未 clear
- 如果看到 reactive({}) → childRef → parentRef → component → 多个组件共用同一响应式对象并互相赋值引用
聚焦四类高危交互场景
循环泄漏极少孤立存在，常通过中间载体放大。优先检查这些模式：
- 事件总线/状态库中的组件挂载：store.activeComponent = this、bus.on('x', this.handler)，必须在 beforeUnmount / componentWillUnmount 中显式解除
- 自定义指令或 UI 库的 DOM 反向引用：如 el._instance、el.__chart、el.__popup，指令 unmounted 钩子里要手动删掉这些属性
- 父传子回调闭包捕获父数据：props.onSave = () => console.log(this.hugeList)，子组件缓存复用时，父组件无法释放 hugeList
- 共享 ref / reactive 对象被双向赋值：shared.state.child = childComp；childComp.parent = parentComp —— 两者生命周期不同步，极易滞留
验证是否真为泄漏而非设计闭环
Vue 的依赖收集、React 的 Fiber 树节点之间天然存在父子/兄弟引用，这类是框架内部管理的“安全循环”。判断标准有二：
- 反复挂载卸载同一组件，其堆快照中实例数量是否持续增长（不是瞬时升高，而是每次多留 1–2 个）
- 该组件实例的 Retaining Path 中，是否存在非框架内部路径（如 window.xxx、document.getElementById、setInterval、某个长期存活 store 的属性）
修复核心：切断强引用链，不依赖 WeakMap
WeakMap / WeakRef 无法触发自动清理逻辑，也不适合管理组件关系。可靠做法是主动解绑：
- 事件监听统一用 on + off 配对，避免匿名函数；bus 使用符号键或唯一 ID 管理订阅
- DOM 属性绑定后，务必在组件卸载钩子中 delete el.__xxx
- 闭包回调改用参数传递代替捕获：onSave={(data) => emit('save', data)}，而非捕获整个 this
- 共享状态改用只读 proxy 或拆分为独立作用域的局部 ref，避免跨组件直接赋值实例
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
