Pinia Action 默认不协调并发请求，需主动设计控制策略：读操作可并行但须隔离状态，写操作应串行或加锁，高频场景用AbortController取消冗余请求，状态管理按key隔离，关键操作需轻量级执行锁。
Pinia 的 Action 本身不禁止并行执行，但默认不会自动协调多个并发请求——是否允许、如何控制、怎样避免状态错乱，全靠你主动设计。关键不在“能不能并行”，而在“要不要并行”以及“并行时怎么管好状态和资源”。
明确是否需要真正并行
多数场景下，并行不是目标，而是副作用。比如用户快速点击两次“刷新列表”，触发两个 fetchList；或搜索框输入过程中连续发请求。这类情况更应考虑防抖、节流或取消前序请求，而非放任并行。
- 对读操作（如列表、详情），可接受并行，但需确保每次响应只更新对应请求的正确状态（例如用请求 ID 区分）
- 对写操作（如提交表单、修改配置），通常应串行或加锁，避免后发先至导致数据覆盖
- 若业务逻辑本身依赖顺序（如“先保存草稿 → 再发布”），必须显式控制执行链路，不可依赖并行
用 AbortController 主动取消冗余请求
适用于搜索、自动补全、实时筛选等高频异步场景。在 Action 中为每次请求创建独立的 AbortController，并在新请求发起前调用 abort()。
- 把 controller 实例存在 store 属性里（如
this.searchController），便于复用和清理 - fetch 或 axios 调用时传入
signal选项，浏览器会自动中断挂起请求 - 在
finally块中重置 controller，避免残留
隔离并发请求的状态字段
当多个同类请求（如加载不同用户的资料）可能同时进行时，不要共用一个 loading 或 error 字段，否则状态互相干扰。
- 用 Map 或对象按 key 管理：例如
this.userStatus = new Map()，存id → { loading: true, data: null, error: null } - 组件中通过
store.getUserStatus(id)获取对应状态，而不是全局 loading - 配合
$onAction监听器，可统一注入请求 ID 并自动初始化/清理条目
必要时加轻量级执行锁
对不能并行的关键操作（如支付确认、库存扣减），可在 Action 开头检查锁状态，避免重复提交。
- 定义
isProcessing: boolean和processingKey: string | null - 进入 Action 时判断
if (this.isProcessing && this.processingKey === key) return - 成功或失败后都重置锁，
finally是最稳妥的位置 - 锁粒度尽量细（如按业务 ID），避免全局阻塞
