处理异步竞态的核心是只更新最新请求结果：用oninvalidate标记过期、abortcontroller中断请求、防抖收敛触发频率，并避免在watcheffect中await阻塞。
处理多个异步并发请求的竞态条件，核心不是“等所有请求完成”，而是确保只有最新一次请求的结果能更新状态。watchEffect 本身不阻塞、不等待 Promise，所以必须主动拦截过期响应。
用 onInvalidate 标记并丢弃旧任务
每次 watchEffect 执行时，都可能开启新请求；上一轮未完成的请求就该被判定为“过期”。关键是在发起异步操作前注册清理逻辑，并在响应返回后检查是否已被取消：
- 在 watchEffect 回调中接收 onInvalidate 参数
- 声明一个局部变量（如 let canceled = false）作为取消标记
- 调用 onInvalidate(() => { canceled = true })，这样下一次 watchEffect 触发时，上一轮的清理函数会先执行
- await 请求后，第一件事是判断 if (canceled) return，跳过后续赋值
配合 AbortController 主动中断网络请求
仅靠标记位不能真正终止请求，尤其对 fetch 或 axios 来说，AbortController 能让浏览器层面停止传输，节省带宽和资源：
- 每次 watchEffect 执行时新建 const controller = new AbortController()
- 把 controller.signal 传给 fetch 的 options
- 在 onInvalidate 中调用 controller.abort()
- 响应处理中检查 response.ok && !signal.aborted，双重防护
防抖 + 竞态拦截双保险
高频输入（如搜索框）导致的频繁触发，本质是源头太“毛躁”。与其在每次 watchEffect 里硬扛竞态，不如先收敛变化流：
- 用 useDebounce(searchKey, 300) 包裹原始响应式数据
- watchEffect 监听的是这个防抖后的 ref，自然大幅减少触发次数
- 再叠加上面的 onInvalidate + AbortController 方案，兼顾频率控制与顺序保障
避免在 watchEffect 内部 await 长时间 pending 的 Promise
watchEffect 的回调是同步启动的，但 await 会让后续代码进入微任务队列。这会导致两个问题：依赖收集不完整、逻辑执行时机不可控：
- 不要写 await fetchData() 后再读取其他 ref —— 后续依赖不会被追踪
- 更稳妥的做法是：先读取所有需要的响应式值（同步部分），再发起请求
- 如果必须串行等待，考虑拆成独立的 effect 或用普通 async 函数配合手动触发
