pinia 的 action 本身不提供批量执行机制，需通过 $patch 合并多次状态更新以避免重复响应式通知；推荐在单个 action 内用对象式或函数式 $patch 一次性提交变更，复杂表单应聚合更新时机，配合 $subscribe 控制副作用触发。
Pinia 的 action 本身不提供“批量执行”机制，但通过合理设计 action 内部逻辑 + 正确使用 $patch，就能实现多次状态更新的性能优化。核心思路是：**避免在单个 action 中多次直接赋值 state 字段，改用 $patch 一次合并所有变更**。
为什么不能靠多个 action 调用来“批量”？
每个 action 默认是独立执行单元。如果你写成这样：
store.updateName('A')store.updateAge(28)store.updateActive(true)
——这会触发 3 次响应式更新、3 次依赖通知、最多 3 次组件重渲染。即使它们都在同一个事件回调里，Pinia 也不会自动合并。
推荐做法：在 action 内部用 $patch 合并更新
把多个字段更新封装进一个 action，并用 $patch 统一提交：
- 对象式（适合字段明确、无依赖计算）：
this.$patch({ name: 'A', age: 28, isActive: true }) - 函数式（适合需读取当前值、做数组操作或条件判断）：
this.$patch(state => { state.count++; state.items.push(newItem); })
这样无论改几个字段，都只触发 1 次响应式通知和 1 次重渲染，DevTools 里也只记录 1 条 patch 日志。
复杂表单场景：结合 storeToRefs + $patch 避免过度响应
当组件中要同步多个输入框到 store，别用 watch 多次调用 action，而是：
- 用 storeToRefs 提取需要响应的字段（如
name,email），避免监听整个 store - 在表单提交或防抖后，一次性
store.$patch({ name, email, phone }) - 不建议在 input change 时就 $patch —— 频繁小更新反而增加开销，应聚合时机
进阶技巧：用 $subscribe 控制副作用触发时机
如果 action 更新后还需触发 API、日志或本地存储等副作用，别在每次赋值后都写逻辑。利用 $subscribe 监听 patch 完成后的最终状态：
store.$subscribe((mutation) => { if (mutation.type === 'patch object') saveToLocalStorage(store.$state) })- 配合
{ detached: true }可全局监听，避免重复注册 - 确保副作用只在真正完成的批量更新后执行一次，而不是被拆散的多次更新反复触发
