watcheffect 无法追踪 await 后读取的响应式变量，需提前在同步阶段访问以收集依赖；推荐用 computed 封装组合依赖、ontrigger 调试或改用 watch 处理异步后置读取场景。
核心问题在于：watchEffect 只在函数**同步执行阶段**收集依赖，一旦遇到 await，后续代码属于异步微任务，此时依赖收集早已结束，再读取响应式变量也不会被追踪。
把异步逻辑中要用的响应式值提前“拉到同步层”
确保所有需要响应式追踪的变量，在第一个 await 之前就被访问一次。这样它们才能进入依赖列表。
- 错误写法（
page.value在 await 后才读，不会被监听）：watchEffect(async () => {<br> if (searchQuery.value) {<br> const res = await fetch(`/api?q=${searchQuery.value}`);<br> // ❌ page.value 这里才读，不触发重运行<br> data.value = await res.json();<br> isLoading.value = false;<br> }<br>}); - 正确写法（提前读取，显式纳入依赖）：
watchEffect(async () => {<br> // ✅ 提前访问，强制收集依赖<br> const q = searchQuery.value;<br> const p = page.value;<br> if (!q) return;<br> const res = await fetch(`/api?q=${q}&page=${p}`);<br> data.value = await res.json();<br> isLoading.value = false;<br>});
用计算属性或 ref 封装组合依赖（推荐用于复杂场景）
把多个响应式源“打包”成一个单一、稳定的响应式信号，让 watchEffect 只需追踪它。
- 例如：
const searchKey = computed(() => `${searchQuery.value}-${page.value}`);<br>watchEffect(async () => {<br> if (!searchQuery.value) return;<br> const res = await fetch(`/api?q=${searchQuery.value}&page=${page.value}`);<br> data.value = await res.json();<br>});
→ 改为追踪searchKey.value，变化即代表组合条件更新 - 优势：逻辑清晰、避免漏依赖、也便于手动控制触发时机
用 onTrigger 钩子验证实际追踪了哪些值
开发阶段开启调试，确认依赖收集是否符合预期。
- 加一句
onTrigger: (e) => console.log('triggered by', e.key, 'on', e.target)到 watchEffect 选项中 - 修改数据后观察控制台：如果某个你认为该响应的 ref 没出现在日志里，说明它没被收集——大概率是它只在 await 后被读取
- 这是最直接的“验错”手段，比猜更可靠
对必须延迟读取的场景，改用 watch
如果业务逻辑天然要求“先发请求，等返回后再读某个状态做判断”，那 watchEffect 并不适合——这不是它设计的场景。
- 这种强时序依赖 + 异步后置读取，更适合用
watch([a, b], async ([newA, newB]) => {...}) - watch 显式声明依赖，语义明确，且支持 immediate，也能覆盖初始化需求
- 不必硬套 watchEffect；选型看数据流逻辑，不是越自动越好
