Pinia Actions 处理并发请求的关键是主动设计状态更新时机与数据归属关系，需用 AbortController 控制请求生命周期、为每个请求分配独立状态字段、合理使用 $patch 批量提交变更。
Pinia Actions 处理并发请求的关键不是“自动同步”，而是**主动设计状态更新时机与数据归属关系**，避免竞态、覆盖和 UI 错乱。核心在于：用 AbortController 控制请求生命周期 + 明确每个请求对应的状态字段 + 合理使用 $patch 批量提交变更。
为每个并发请求分配独立状态字段
不要让多个请求共用同一个 data/loading/error 字段。否则后发起的请求完成时，可能覆盖先发起但慢响应的结果。
- 比如搜索建议（searchSuggestions）、用户资料（userProfile）、权限列表（permissions）应各自有独立状态：
- searchLoading / searchResults / searchError
- profileLoading / profile / profileError
- permsLoading / perms / permsError
用 AbortController 主动取消过期请求
尤其适用于输入联想、筛选条件频繁变化的场景。每次新请求发起前，取消上一次未完成的请求，防止旧响应错误覆盖新状态。
- 在 store 中声明 controller 引用（如 this.searchController）
- 发起请求前调用 this.searchController?.abort()
- 创建新 controller：this.searchController = new AbortController()
- 将 signal: this.searchController.signal 传给 fetch 或 axios
并发请求完成后统一整合状态（可选）
如果多个请求结果需共同决定某个 UI 状态（例如“页面是否准备就绪”），可用 Promise.all + $patch 一次性提交最终状态：
- 定义一个聚合状态字段，如 isPageReady: boolean
- 在 action 中并行触发请求，并用 Promise.allSettled 处理全部完成（含失败）
- 根据各请求结果设置对应字段后，调用 this.$patch({ isPageReady: true, ... })
- 避免在每个请求的 then/catch 里单独改 isPageReady —— 容易因顺序或失败被多次覆盖
避免在组件中手动触发多个 action 导致状态割裂
不要这样写：
- store.fetchUser()
- store.fetchPosts()
- store.fetchStats()
而应在 store 内封装一个组合 action，比如 loadDashboard()，内部按需并发调用并管理彼此依赖与错误回退逻辑。
