滥用 watch 导致的逻辑混乱

watch 是 Vue 中一个强大且常用的 API，它能监听响应式数据的变化并执行副作用。但它的强大也带来了一个常见的反模式：把 watch 当成“万能回调”，用它来处理本该由计算属性、事件处理或组件通信解决的逻辑。当项目中出现大量 watch 相互触发、循环依赖时，代码会变得难以追踪和理解。

常见滥用场景与替代方案

1. 用 watch 计算衍生值 → 应使用 computed

<script setup>
import { ref, watch } from 'vue'

const firstName = ref('')
const lastName = ref('')
const fullName = ref('')

// ❌ 滥用 watch：手动同步衍生值
watch([firstName, lastName], ([first, last]) => {
  fullName.value = first + ' ' + last
})
</script>

这个问题在于：fullName 完全由 firstName 和 lastName 同步派生，不存在异步或副作用。应改用计算属性：

<script setup>
import { ref, computed } from 'vue'

const firstName = ref('')
const lastName = ref('')
const fullName = computed(() => firstName.value + ' ' + lastName.value)
</script>

computed 具备缓存机制且自动追踪依赖，代码更清晰，也避免了手动维护 fullName 的赋值逻辑。

2. 数据变化后执行某个动作 → 应直接在事件处理中完成

很多开发者习惯在 watch 中调用 router.push 或修改其他状态，而这种变化其实完全可以由触发源直接处理。

<script setup>
import { ref, watch } from 'vue'
import { useRouter } from 'vue-router'

const keyword = ref('')
const router = useRouter()

// ❌ 滥用 watch：关键词变化后跳转
watch(keyword, (val) => {
  if (val) router.push({ query: { q: val } })
})
</script>

更好的方式是把跳转逻辑放在触发输入事件的方法中，或者直接使用表单提交事件：

<script setup>
function search(keyword) {
  if (keyword) router.push({ query: { q: keyword } })
}
</script>

这样，逻辑的源头和流向一目了然，不需要通过 watch 多绕一层。

3. 多个 watch 形成依赖链 → 状态更新混乱

当 watch A 修改数据 B，watch B 又修改数据 C，甚至回调中又触发了 watch A，最终导致不可预测的连锁反应。比如一个表单的“省份-城市-区县”三级联动若全用 watch 串联，很容易出现死循环或时序错乱。

解决方案：对于联动逻辑，尽量将驱动关系集中在一个函数中，或使用 watch 的 { immediate: false } 和明确的条件判断，避免隐式依赖。更彻底的方案是使用状态机或集中式事件处理。

4. 在 watch 中做复杂异步竞态 → 应使用 watchEffect 或专门的异步管理工具

当 watch 的回调包含异步请求，且依赖频繁变化时，需要手动管理竞态（旧请求的响应不能覆盖新请求）。虽然 Vue 3 的 watch 提供了 onCleanup 参数来处理竞态，但很多开发者会忽视，导致界面闪现旧数据。

// ❌ 容易因竞态导致数据错乱
watch(keyword, (newVal) => {
  fetchResults(newVal).then(data => { results.value = data })
})

推荐使用 watchEffect 结合 onCleanup 来优雅处理：

watchEffect((onCleanup) => {
  let cancelled = false
  onCleanup(() => { cancelled = true })
  fetchResults(keyword.value).then(data => {
    if (!cancelled) results.value = data
  })
})

或者直接使用 TanStack Query 等专门管理异步状态的库，它们内部已处理好竞态与缓存。

为什么 `watch` 容易导致逻辑混乱？

隐性依赖：watch 的回调修改其他数据，被修改的数据可能又被其他 watch 监听，形成难以梳理的数据流。
时间差：watch 默认异步执行且可能因 flush 选项改变时机，开发者容易对这个“延迟”产生困惑。
调试困难：多个 watch 互相触发时，很难通过断点或日志还原完整的调用链。

最佳实践

能用 computed 就不用 watch：衍生值、格式化、条件判断等纯计算逻辑，一律用 computed。
能用事件处理就不用 watch：用户交互产生的变化，直接在事件处理函数中完成后续动作。
使用 watchEffect 自动追踪：对于多个依赖的副作用，watchEffect 会自动收集依赖且提供 onCleanup 机制，减少手动管理。
限制 watch 的数量：如果一个组件内出现了 3 个以上 watch，就要审视是否应该重构为自定义 Hook 或使用状态机。
明确副作用：watch 只应用于真正无法通过其他方式实现的副作用：操作 DOM、异步请求、订阅外部事件、日志记录等。

记住：watch 应该是你最后的选择，而不是第一反应。当一个逻辑可以被声明式地表达（计算属性、模板表达式）或被直接调用（事件处理），就不要引入间接的监听回调。干净的代码往往只需要很少的 watch。

常见滥用场景与替代方案

为什么 watch 容易导致逻辑混乱？

最佳实践

为什么 `watch` 容易导致逻辑混乱？