Pinia 的 Actions 本身不自动合并多次调用，需通过单个 action 封装批量更新、使用 $patch 一次性提交、统一异步处理、$onAction 管理副作用及防抖提交来实现高效批量操作。
Pinia 的 Actions 本身不自动合并多次调用，但通过合理设计可以实现“批量操作数据的接口调用”——关键不是让多个 action 调用变“批量”，而是把原本分散的更新逻辑收束到一个 action 内，配合一次性状态提交和统一的异步处理流程。
用单个 action 封装批量更新 + $patch
避免写多个独立 action（如 updateName、updateEmail、updatePhone）再挨个调用。它们会触发多次响应式通知和组件重渲染。
- 在同一个 action 中收集所有待更新字段，用 $patch 一次性提交：
this.$patch({ name, email, phone, avatarUrl })
- 若需读取当前 state 做判断（比如追加数组项或累加计数），改用函数式 $patch：
this.$patch(state => { state.items.push(...newItems); state.total += newItems.length; })
- 这样无论改多少字段，只触发 1 次响应式更新、1 次 DevTools 日志、1 次组件 re-render。
批量接口调用：一个 action 对应一次后端请求
当业务需要“一次提交多个数据给后端”（如批量导入用户、批量更新商品状态），应在 action 中发起单次 HTTP 请求，而不是循环调用多个请求。
- 把待提交的数据数组作为参数传入 action：
async batchUpdateProducts(products) { this.loading = true; try { const res = await api.patch('/products/batch', { items: products }); this.$patch({ list: res.data }); } finally { this.loading = false; } }
- API 层应支持批量接口（如 RESTful 的 /batch 端点或 GraphQL 的 mutation 批量字段）；前端不拼接多个请求，避免竞态与超时叠加。
- 服务端返回成功/失败明细时，可在 action 中分类处理（如高亮失败项、保留成功项状态）。
结合 $onAction 统一管理批量操作的副作用
批量操作常伴随 loading、错误提示、日志上报等通用逻辑。不建议每个 action 都重复写 try/catch 和状态开关。
- 使用 $onAction 全局拦截，在 action 开始前设 loading，结束后清空，出错时统一提示：
pinia.use(({ store }) => { store.$onAction(({ name, after, onError }) => { if (name.startsWith('batch')) { store.loading = true; after(() => store.loading = false); onError(() => store.loading = false); } }); });
- 也可按命名约定（如 action 名含 batch、multi）做差异化控制，保持灵活性。
复杂表单场景：延迟聚合 + 防抖提交
用户在表单中频繁修改多个字段时，不要每次 input change 都触发 $patch 或 API 调用。
- 用 storeToRefs 解构需要响应的字段，避免监听整个 store；
- 将输入值暂存于局部 ref 或 computed，仅在提交、失焦或防抖后（如 300ms）执行一次 batchSave action；
- 该 action 内部调用 $patch 更新本地状态，并发一次批量接口请求同步到后端。
这样既保证交互响应性，又避免无效请求和状态抖动。
