异步任务状态统一管理需集中定义pendingkeys、errors、results等字段，通过唯一语义化key标识任务，封装runasync执行器确保生命周期对齐，并支持多任务协同与组合状态计算。
异步任务执行状态的统一管理，核心在于把“谁在跑、跑得怎样、何时结束、出错了没”这些信息从散落在各处的组件或方法里收拢起来，形成可观察、可响应、可复用的状态视图。它不是单纯加个 loading 变量，而是建立一套与业务逻辑解耦、跨组件共享、支持并发与错误归因的状态机制。
状态集中定义：避免每个请求都写一遍 loading / error / data
分散管理容易导致状态命名不一致（如 isLoading / isPending / fetching）、生命周期错位（组件卸载后更新已销毁状态）、以及无法全局感知当前有哪些任务正在运行。推荐做法是：
- 在状态管理方案（Redux、Zustand、Pinia 或 Context + useReducer）中，为异步任务定义统一的 slice 或 store 模块，字段至少包含：pendingKeys（正在运行的任务标识集合）、errors（按任务 key 映射的错误）、results（缓存成功结果）
- 每个异步操作应携带唯一、语义化的 key（如
"user/profile/fetch"或"order/submit"），而非仅用布尔值控制全局 loading - 提交任务时自动加入 pendingKeys；完成（无论成功或失败）时自动移除，并更新对应 errors 或 results
任务标识与生命周期绑定：让状态真正反映实际执行
光有 key 不够，还需确保状态变更与真实任务生命周期严格对齐。常见陷阱包括：
- Promise 被忽略或未 await 导致状态未清理（例如调用了 API 但没 catch 或没 await 返回的 Promise）
- 组件多次触发同一任务却未去重，造成 pendingKeys 累积或结果覆盖
- 取消机制缺失，用户离开页面后仍在后台更新已卸载组件的状态
- 解决方案：封装统一的 async 执行器（如
runAsync(key, fn)），内部自动处理 pending 加入、try/catch 清理、AbortSignal 支持取消，并返回带 cancel 方法的 Promise
多任务协同与组合状态：应对真实业务复杂度
单个页面常需并行加载多个资源（用户信息 + 权限 + 首页数据），或串行执行（先登录再拉配置）。统一管理需支持：
-
组合状态计算：例如导出按钮禁用条件 = “任意相关任务 pending”，可用
selectIsAnyPending(["export/start", "export/progress"])实现 -
依赖链追踪：若 B 依赖 A 完成，可在状态中记录
dependsOn: ["user/login"]，A 失败时自动标记 B 为 skipped -
局部状态隔离：不同模块使用不同 key 前缀（如
dashboard/vssettings/），避免互相干扰，同时保留全局汇总能力
async 函数本身不是状态管理器：它只负责执行，不负责表达状态
async/await 是语法糖，解决的是“如何非阻塞地跑任务”，而非“如何告诉 UI 当前跑得怎样”。很多团队误以为写了 async 就等于有了状态管理——其实只是把回调地狱换成了 await 地狱，loading 依然靠手动开关。关键区别在于：
- async 函数返回 Promise，它本身不含 loading/error/data 字段
- 状态管理必须显式监听 Promise 生命周期（then/catch 或 try/catch），并将结果映射到可订阅的状态源
- React 中推荐结合 Suspense + useTransition 或自定义 Hook（如
useAsync({ promise })）做轻量封装，但复杂场景仍需集中 store 支撑
