pinia 的 actions 通过 async/await 串行调用、跨 store 组合、状态驱动分支、封装流程函数等方式实现任务编排。关键在于设计模式而非框架内置机制，支持条件执行、错误回滚与原子性保障。
Pinia 的 actions 本身不提供原生的任务队列或依赖调度机制，但通过合理组织逻辑、组合调用和状态协同，完全可以实现清晰可控的“任务编排”——即多个异步操作按需串行、并行、条件执行或错误回滚。关键不是靠框架内置功能，而是靠设计模式和约定。
用 async/await 显式控制执行顺序
最直接可靠的方式是把多个 action 调用写在同一个 async action 内，用 await 逐个触发，确保前序完成再执行后续：
- 适合有明确先后依赖的流程，比如“登录 → 获取权限 → 加载主数据”
- 可在中间插入条件判断、重试逻辑或状态校验（如检查 token 是否过期）
- 错误可统一 try/catch，便于集中处理或中断整个流程
跨 store action 组合调用
一个业务动作常涉及多个领域状态，例如下单要更新购物车、用户积分、库存和订单列表。这时应在顶层 store（如 orderStore）中 import 并调用其他 store 的 action：
- useCartStore().clearCart()
- useUserStore().deductPoints(amount)
- useInventoryStore().decreaseStock(items)
- 所有调用都用 await，保证原子性；任一失败可 catch 后 rollback 已执行步骤
状态驱动的条件分支编排
把“是否执行某 action”交给 store 自身状态决定，而不是由组件传参控制。例如：
- 定义一个 status 字段：'idle' | 'validating' | 'ready' | 'submitting'
- 在 submitOrder action 中先检查 this.status === 'ready'，否则直接 return 或 throw
- 其他 action（如 validateForm）成功后自动设为 'ready'，形成状态机式的流程推进
封装可复用的流程函数（非 store 内）
对高频复用的多步流程（如“搜索→防抖→取消上一次→加载→缓存”），可抽离为独立工具函数，接收 store 实例或相关 action 作为参数：
- 避免在每个 store 里重复写 abortController + loading + error 模板
- 函数返回 Promise，仍可被上层 action await，保持调用链清晰
- 类型安全友好，TS 可精确推导入参和返回值
