不能在 watchEffect 回调中直接声明 async 函数，因会破坏依赖收集、导致清理失效和无限循环；正确做法是封装 async/await 为普通函数，在 watchEffect 内同步调用，并用 AbortController 和 cancelled 标记精准控制请求生命周期。
不能在 watchEffect 回调里直接声明 async 函数，因为这会破坏依赖收集、导致清理失效，还可能引发无限循环。真正“优雅结合”的关键，是把 async/await 封装进普通函数，在 watchEffect 内同步调用它，并配以 AbortController 和状态标记做精准控制。
别写 async watchEffect —— 依赖收集会断掉
下面这种写法是错误的：
watchEffect(async () => { const data = await fetch('/api'); state.value = data })- 问题：
await之后的代码（比如赋值）不在依赖收集阶段执行，state.value的变更不会被当前watchEffect追踪到 - 更严重的是，
onCleanup可能根本没机会注册，旧请求无法取消，界面容易显示过期数据
正确结构：先注册清理，再发起请求
标准四步必须按顺序来：
- 创建
AbortController实例 - 用
onCleanup(() => controller.abort())注册取消逻辑（注意：必须在 fetch 前！） - 调用
fetch(url, { signal: controller.signal })或axios.get(url, { signal }) - 在
.then()或await后检查是否已取消，再更新状态
加 cancelled 标记兜底，防响应覆盖
即使 abort 触发了，fetch 仍有可能在 resolve 后才进入 then，这时需要二次判断：
- 定义
const cancelled = ref(false) - 在
onCleanup中设cancelled.value = true - 异步成功后写：
if (!cancelled.value) state.value = data - 错误处理时只捕获非
AbortError的异常，避免把取消当失败上报
按场景选取消策略：网络请求 vs 状态跳过
不是所有异步都需要中断请求：
- 对网络延迟敏感的搜索、筛选：用
AbortController真正中止请求 - 对渲染或计算类操作（如 debounce 后的本地过滤）：用
isActive = ref(true)+onCleanup(() => isActive.value = false)，回调开头加if (!isActive.value) return，不发请求，只跳过赋值
