优先选watch解决需比对新旧值的场景，如权限跳转、状态通知、表单校验；watcheffect适用于依赖动态、只需响应“有变化”的场景，如搜索建议。

选 watchEffect 还是 watch，不看“哪个更高级”，只看“你要解决什么问题”。用错一个，轻则逻辑难懂、调试费劲，重则请求发重、内存泄漏、页面卡顿。

需要知道“从哪来、到哪去”时，用 watch

比如权限变更后跳转不同页面、订单状态从“待支付”变成“已发货”才触发通知、表单校验依赖上一步输入结果——这些都得比对新旧值才能判断该做什么。

• watch 回调直接提供 newValue 和 oldValue，无需自己缓存或打标记
• 支持 immediate: true，初始化就能拿到初始值和 undefined（或上一次缓存值）
• 监听对象深层属性？加 deep: true 即可，语义清晰、控制明确
• 监听计算属性或 getter 函数？watch 写法直观，链路可追溯，别人接手一眼就懂

多个响应式数据一起变、你只关心“有变化”时，用 watchEffect

像搜索建议框：关键词、筛选标签、排序方式任意一个动了，都要重新拉列表。你不需要知道谁先谁后，只要“有东西变了”就执行。

• watchEffect 自动收集回调里读取的所有响应式依赖，不用手动列数组
• 创建即执行一次，省去额外触发逻辑
• 适合带清理的副作用：比如在回调里开 WebSocket，它的清理函数会自动在下次执行前关掉旧连接
• 代码更简洁，尤其当依赖项动态增减（比如动态表单项）时，维护成本更低

高频更新或对执行时机敏感，优先选 watch

鼠标位置、滚动偏移、传感器实时数据……这类值每秒变几十次。用 watchEffect 容易频繁重跑，拖慢页面。

• watch 可设 flush: 'post' 延迟到 DOM 更新后执行，避免重复渲染
• 也可用 flush: 'sync' 强制同步，适合必须立刻响应的场景（如焦点管理）
• 默认懒执行，只在真变化时跑，减少无谓开销
• 团队协作或长期迭代项目里，watch 的显式声明本身就是一份轻量文档

依赖隐含、重构风险高，慎用 watchEffect

watchEffect 的依赖是“读到啥就追踪啥”，删掉一行读取语句，可能就悄悄漏掉一个监听项；加个条件分支，还可能造成依赖收集不全。

• watch 的监听源写在第一个参数里，改需求时增减目标一目了然
• watchEffect 隐式依赖让调试变难，尤其嵌套逻辑或条件执行较多时
• 如果副作用涉及关键业务流程（如支付确认、权限锁定），建议宁可多写两行，也用 watch 明确控制