watcheffect 不适合直接执行异步请求，应将其作为触发器调用封装好的异步函数，并手动控制 loading 状态；推荐改用 watch，明确监听目标、控制执行时机，流程更清晰可控。
直接用 watchEffect 执行异步请求容易出问题——它只在同步阶段收集依赖，await 后面的响应式变量变化不会触发重新执行，还可能引发竞态或无限循环。正确做法是把 loading 状态和数据加载逻辑显式拆开，配合手动控制。
明确区分状态与副作用
不要让 watchEffect 直接发起请求并更新数据。它适合做“触发器”，而不是“执行器”。真正加载数据、切换 loading 的逻辑应放在独立函数里，由 watchEffect 调用：
- 定义
loading和data两个 ref，用于视图绑定 - 把 API 调用封装成普通 async 函数（如
fetchUser()） - 在
watchEffect中仅调用该函数，并在前后手动控制loading.value
手动管理 loading 流转（推荐）
这是最可控、不易出错的方式。示例中监听一个搜索关键词，变化时加载用户列表：
const keyword = ref('')
const users = ref([])
const loading = ref(false)
watchEffect(async (onCleanup) => {
if (!keyword.value.trim()) return
loading.value = true
const controller = new AbortController()
onCleanup(() => controller.abort())
try {
const res = await fetch(`/api/users?q=${keyword.value}`, {
signal: controller.signal
})
users.value = await res.json()
} catch (err) {
if (err.name !== 'AbortError') {
console.error(err)
}
} finally {
loading.value = false
}
})
- 每次 watchEffect 执行前设
loading.value = true，结束时设false - 用
onCleanup注册中断逻辑，避免旧请求结果覆盖新请求 - catch 中过滤
AbortError，防止误报错误
避免常见陷阱
以下写法看似简洁，但实际不可靠：
-
不要在 watchEffect 回调里直接 await 响应式变量赋值：比如
data.value = await fetch(...)，后续对data的修改不会被追踪，也无法触发重试 -
不要依赖异步代码中的响应式读取作为依赖项：例如
if (keyword.value) { const res = await ...; page.value = res.page }，page.value不会被自动监听 - 慎用 immediate: true 配合异步：初始化时 loading 状态可能没及时反映，建议首次加载单独处理或加延时判断
替代方案：用 watch 更清晰
如果依赖源固定（比如一个 ref 或几个 props），watch 往往比 watchEffect 更合适：
- 能明确指定监听目标，避免隐式依赖
- 支持
immediate和flush: 'post'控制执行时机 - 天然适配“监听 → 显示 loading → 请求 → 更新数据 → 关闭 loading”流程
多数业务场景中，watch 的意图更明确，调试和维护成本更低。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
