watchEffect 处理异步需谨慎：依赖仅同步收集，await 后响应式读取不被追踪；须提前读取依赖、用 onCleanup 清理请求、避免修改依赖源引发循环；flush 不宜设 sync，精细控制应选 watch。
可以，但必须谨慎处理依赖收集、清理和执行时机，否则容易出错或泄漏。
依赖收集只在同步阶段生效
watchEffect 的依赖是“边执行边收集”的，且仅限同步代码。一旦遇到 await，后续逻辑进入微任务队列，此时依赖收集早已结束，导致：
- 异步块里读取的响应式数据（比如
data.value）不会被追踪 - 这些数据后续变化，不会触发 watchEffect 重新执行
✅ 正确写法：把要监听的响应式值提前放在 await 前使用
const id = ref(1)const data = ref(null)
watchEffect(() => {
console.log('ID is:', id.value) // ✅ 被收集
// await fetchData(id.value) // ❌ fetchData 内部用到的响应式值不会被收集
})
必须手动清理未完成的异步请求
用户快速切换条件（如频繁修改 id），旧请求可能还在 pending，新请求已发出，造成竞态问题或覆盖错误结果。
立即学习“前端免费学习笔记（深入）”；
✅ 解决方式：利用 onCleanup 注册取消逻辑
watchEffect((onCleanup) => {const { response, cancel } = doAsyncWork(id.value)
onCleanup(cancel) // ✅ 上次执行前自动调用 cancel
data.value = await response
})
避免无限循环触发
如果异步回调中直接修改了 watchEffect 依赖的响应式变量，就可能形成“修改 → 重新执行 → 再修改”死循环。
- 例如：watchEffect 中 await 后赋值给
state.data，而该 state 正是 watchEffect 的依赖源之一 - 解决办法：确保异步结果写入的变量不在当前依赖路径上；或用独立状态（如
result）承接，不参与依赖收集
注意执行时机与 flush 配置
默认 flush: 'pre'（组件更新前执行），适合大多数副作用；若需操作更新后的 DOM，可设 flush: 'post'；但不要设为 'sync'，尤其含 await 时，会阻塞渲染并破坏响应性。
另外，watchEffect 不提供新/旧值对比，也不支持 deep 或 immediate 选项 —— 这些是 watch 的能力，异步场景若需要更精细控制（比如只在变化后执行、获取 oldValue），应优先考虑 watch + async 回调。
