Pinia 通过组合 actions、显式调用其他 Store、响应式 getters、手动状态快照回滚及抽离组合函数等方式，模拟跨 Store 原子操作。

Pinia 本身不提供“事务”概念，但可以通过组合 actions、合理调用顺序和状态协同来模拟跨 Store 的原子性操作。关键不是强制锁定多个 Store，而是让逻辑流转清晰、错误可回滚、状态更新可预测。

在 action 中显式调用其他 Store

这是最常用也最可控的方式。一个业务动作需要协调多个模块时，由主 Store 的 action 统一发起，按需调用其他 Store 的方法或读取其状态。

• 直接 import 并实例化目标 Store，例如 useUserStore() 和 useCartStore()
• 在当前 action 内完成全部逻辑：先检查用户权限 → 更新购物车 → 提交订单 → 清空临时状态
• 所有操作都在同一个异步上下文中，便于统一 try/catch 和错误处理

用 getters 安全合并跨 Store 数据

当需要“读取多个 Store 状态并计算结果”（如 VIP 折扣价、库存是否充足），优先使用 getters 而非在 state 或 setup 中硬编码调用。

• getter 内部调用 useOtherStore() 是响应式的，依赖自动追踪
• 避免在 state 函数里 import 其他 Store，否则会破坏初始化时机
• 不要把 getter 返回值赋给 const 变量后反复使用，应每次调用获取最新实例

手动实现轻量级“回滚”机制

真正需要事务语义（比如支付失败要还原购物车和积分）时，可在 action 中预先保存快照，并在异常时恢复。

• 调用前用 JSON.stringify(store.$state) 记录原始状态
• 每个关键步骤后检查中间结果，任一环节失败就调用 store.$patch(backup)
• 对涉及多个 Store 的操作，分别备份各自状态，统一管理回滚逻辑

复杂流程建议抽离为组合函数

当跨 Store 协作逻辑变多、复用频繁时，不要堆砌在某个 Store 的 action 里，而是封装成独立的组合式函数。

• 新建 composables/useCheckoutFlow.ts，接收多个 store 实例作为参数
• 函数内部组织调用顺序、错误分支、loading 状态、成功回调等
• 组件或任意 Store 都可按需调用，逻辑集中、类型明确、易于测试