pinia 的 action 调用不自动保证顺序，需显式 await 或链式调用控制；跨 store 调用须避免循环依赖，推荐抽离共享逻辑、封装批量操作为高层 action，并用状态监听替代硬等待。
Pinia 的 action 组合调用本身不自动保证执行顺序，必须靠显式 await 或链式调用控制。关键不是“能不能嵌套”，而是“要不要等、等什么、怎么等”。
明确依赖关系再调用
如果 action B 必须基于 action A 的结果（比如先登录再拉用户信息），就应在 B 中 await A 的执行，或在组件里按需串行调用：
- 在组件中：用 await useAuthStore().login(); await useUserStore().fetchProfile(); 显式控制时序
- 在 action 内部：直接调用另一个 store 的 action，并 await 它的返回值，例如：const token = await this.$auth.login(credentials); this.profile = await api.getUser({ token });
- 避免隐式依赖：不要在未 await 的情况下读取上一个 action 修改的状态，因为异步操作可能尚未完成
跨 Store 调用要避免循环依赖
两个 store 不能在 setup 函数中互相直接初始化对方，但可以在 action 或 getter 中按需调用：
- ✅ 正确：在 useCartStore 的 action 里调用 useUserStore() 获取当前用户 ID
- ❌ 错误：在 useUserStore 的 setup 函数里直接调用 useCartStore()，否则会触发循环引用
- 推荐把共享逻辑（如鉴权检查、通用错误处理）抽到独立工具函数，而非靠 store 互相调用
批量操作建议封装成新 action
多个有先后依赖的 action 合并为一个高层 action，更易复用和测试：
- 例如定义 async initializeApp()，内部按序 await fetchConfig() → checkAuth() → loadUserProfile()
- 这个顶层 action 可统一管理 loading 状态、错误兜底和重试逻辑，比在组件里手动串行更可靠
- 注意不要让单个 action 承担过多职责；若步骤间耦合弱，保留独立 action 更利于单元测试和复用
状态就绪检查比硬等更健壮
有些场景不需要严格等待前一个 action 结束，而是等某个状态变为有效值：
- 用 watch 或 storeToRefs 监听关键字段变化，比如等 user.token 存在后再发起请求
- 配合 until（来自 @vueuse/core）做轮询等待，适用于 token 刷新后需延迟触发后续请求的场景
- 比单纯 await 一个 action 更灵活，尤其适合异步初始化与 UI 渲染节奏不一致的情况
