在 watcheffect 中处理异步操作需显式取消旧请求，推荐用 abortcontroller 配合 oncleanup 实现精准清理；避免直接 async/await，应包裹异步逻辑并加 cancelled 标记兜底，区分 aborterror 与真实错误。
在 watchEffect 中处理异步操作，核心不是“怎么写 async”，而是“怎么确保旧请求不干扰新结果”。Vue 不会自动帮你取消上一次未完成的请求，必须显式干预——否则用户快速输入、频繁切换筛选项时，极易出现界面显示旧数据、内存持续占用、网络资源浪费等问题。
用 onCleanup 注册清理逻辑，绑定 AbortController
这是最推荐、语义最清晰的方式。AbortController 是浏览器原生支持的取消机制，配合 onCleanup 能精准控制副作用生命周期：
- 每次
watchEffect重新执行前，onCleanup自动触发，此时调用controller.abort()可中断正在飞行中的请求 - fetch 和 Axios（1.5+）都支持
signal参数，传入后请求会立即 reject 并抛出AbortError - 注意：清理函数必须在异步操作发起前注册，否则可能错过取消时机
避免在 watchEffect 回调里直接写 async/await
watchEffect 的依赖收集是同步过程，遇到 await 就会中断追踪，导致后续响应式变量变更无法触发重跑；更严重的是，如果 await 后修改了被监听的数据，还可能引发无限循环：
- 正确做法：把异步逻辑包裹在普通函数内，在
watchEffect内同步调用它 - 错误写法：
watchEffect(async () => { await fetch(...) })—— 依赖收集不完整，且无法可靠触发onCleanup - 推荐结构：先声明 controller，注册
onCleanup，再执行fetch或axios.get
加 cancelled 标记兜底，防止旧响应覆盖新状态
即使请求被 abort，也存在极小概率——比如 abort 发生在 fetch 已 resolve 但尚未进入 then 的瞬间。这时需双重保险：
- 定义一个
ref标记（如const cancelled = ref(false)） - 在
onCleanup中设为true，并在异步成功后检查该标记再更新状态 - 捕获异常时，只处理非
AbortError的错误，避免把取消当成失败上报
区分场景选策略：取消请求 vs 跳过赋值
不是所有异步操作都需要 abort。若只是本地计算、过滤或节流渲染，可改用轻量级防抖标记：
- 用
isActive = ref(true)+ cleanup 函数切换状态，让后续回调开头就return - 这种方式不中断网络请求，只跳过 DOM 更新或状态赋值，适合对延迟不敏感但需视图最终一致的场景
- 真正要节省带宽、释放连接、保护服务端资源时，必须走
AbortController路径
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
