watch在非组件环境中会失控，需手动管理生命周期；路由监听应校验当前页面name；immediate与生命周期钩子不可混用；可用Chrome Memory面板定位ReactiveEffect泄漏。
确认 watch 是否在非组件环境中失控
watch 在 <script setup> 或组件 setup() 函数内创建时，Vue 会自动绑定到组件的 EffectScope，卸载时一并清理。但一旦脱离组件上下文——比如写在全局单例类、Pinia Store、纯 TS 工具函数或异步回调里，watch 就成了“孤儿监听器”。它不会被自动注销，持续持有响应式对象引用，导致内存无法回收。
典型错误示例：
- 在
services/notification-manager.ts中直接调用watch(() => store.count, ...)，未保存返回的unwatch函数 - 在
setTimeout或 Promise 回调中创建 watch，丢失了 setup 执行时的当前实例作用域 - 多次调用初始化方法（如用户反复登录），每次新建一个 watch，旧的却一直挂着
检查是否因路由监听引发误触发
监听 route.query.id 或 route.params.id 是常见做法，但容易在页面跳转后仍执行——例如从详情页 A 跳到详情页 B，route.query.id 变了，watch 却在已离开的页面中再次调用数据请求。
安全写法是加一层“当前页面守卫”：
立即学习“前端免费学习笔记（深入）”；
- 确保路由配置中设置了
name（如{ path: '/user/detail', name: 'UserDetail' }） - watch 回调开头判断
if (route.name !== 'UserDetail') return - 避免仅靠参数变化做逻辑，要结合路由语义（name + fullPath 等）确认上下文有效性
识别 immediate 和生命周期钩子的冲突
immediate: true 会让 watch 在创建时立即执行一次。若同时在 onMounted 或 onActivated 中手动调用相同逻辑，就会重复请求或重复渲染。
排查建议：
- 搜索项目中所有
watch(..., { immediate: true })，对照其 handler 是否已在生命周期钩子里出现过 - 把初始化逻辑统一收口：要么全交给
immediate，要么全交给onMounted，不要混用 - 对需要“首次加载 + 后续响应”的场景，可用
ref标记是否已初始化，避免二次进入
用 Chrome DevTools 定位泄漏源头
内存泄漏不能只靠猜。打开 Chrome DevTools → Memory 面板，按标准流程操作：
- 在页面稳定后点击 Take heap snapshot（拍第一个快照）
- 反复进入/退出疑似问题组件（如详情页）3–5 次
- 再拍一个快照，切换到 Comparison 模式，筛选
VueComponent或ReactiveEffect - 重点看数量持续增长的项：如果
ReactiveEffect实例数明显上升，大概率是 watch 泄漏 - 展开可疑对象，查看 Retainers 列表，找谁持有了它——常会看到
targetMap、全局对象、定时器闭包等
主动管理 watch 生命周期
在非组件环境必须手动控制 watch 的启停：
- 始终保存
watch返回值：const unwatch = watch(...) - 在明确的销毁时机调用
unwatch()，比如：Store 的$dispose方法、单例服务的destroy()、组件onBeforeUnmount中转发清理 - 使用
effectScope显式划界：
const scope = effectScope()
scope.run(() => {
watch(...)
watchEffect(...)
})
// 后续可统一调用 scope.stop() 注销全部
