优先选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 明确控制