Reactive对象不会自动释放内存，关键在于是否被活跃引用；需主动清理effect依赖、避免闭包捕获、合理使用toRaw/markRaw，并通过Heap Snapshot验证释放效果。
Reactive 对象本身不会自动释放内存，关键在于它是否被其他活跃对象持续引用。Vue 的 reactive 创建的是响应式代理，其底层依赖 Proxy 和内部的依赖追踪系统（effect、track、trigger）。只要仍有 active effect 持有对它的访问，或它被闭包、全局变量、定时器回调等意外捕获，GC 就无法回收。
必须主动切断响应式对象的依赖链
响应式数据不是“用完即走”的普通对象——它会被 effect（比如 computed、watch、模板渲染）持续订阅。组件卸载时，这些订阅若未清理，reactive 对象及其整个响应式树（包括嵌套的 reactive、ref、computed）都会被 effect 强引用，无法释放。
- 模板中使用的 reactive 数据，由 Vue 自动在组件 unmount 时清理依赖（前提是没逃逸到外部）
- 手动创建的
watch或computed，必须在onBeforeUnmount或onUnmounted中调用其返回的停止函数（stop handle） - 避免在 watch 回调中直接修改另一个大型 reactive 对象——这会延长它的生命周期；改用浅层更新或 ID 引用
防止 reactive 对象被闭包意外持有
最隐蔽的泄漏点：你在 setup 中定义了一个 reactive，又把它传给了 setTimeout、第三方库、事件监听器或 API 回调，这些地方形成了闭包引用，导致整个对象树锁死在内存里。
- 不要在
setTimeout(() => { console.log(state) }, 1000)中直接访问state；改用state.id或序列化字段 - 向第三方 SDK 传 reactive 对象前，先解构出必要字段，或用
toRaw获取原始对象（仅当确定不再需要响应性时） - 避免把 reactive 对象挂到
window.xxx或全局 Map/Array 中，这类引用永不释放
大型 reactive 数据要按需创建与销毁
一个包含上万条记录的 reactive({ list: [...] })，即使组件已卸载，只要还有某处保留着对它的引用（比如缓存、未清理的 watch），它就一直占着内存。
- 优先使用
ref+shallowRef或markRaw包裹不可变大数据（如图表原始 JSON），避免响应式开销和误引用 - 在
onUnmounted中显式清空大数组：state.list = []；置空比留着旧引用更利于 GC 识别可回收区域 - 对长期存在的 reactive 状态（如全局 store），考虑用
resetStore或分片管理，避免单个对象无限膨胀
配合 DevTools 验证是否真正释放
别只看组件是否消失。打开 Chrome Memory 面板 → 拍摄 Heap Snapshot → 执行组件挂载/卸载循环 → 再拍快照 → 切换 Comparison 视图，筛选 VueReactiveObject、VueComputedRefImpl、Closure 的 Delta：
- 若数量随操作次数线性增长，说明依赖未断或对象被闭包捕获
- 重点检查 Retainers 树：找到是谁在 holding 它（比如某个未清除的 timer、window listener、或未 stop 的 watch）
- 用
console.memory辅助观察 JS 堆变化趋势，但以快照对比为准
