pinia actions 应将表单提交与状态更新封装为完整语义单元，优先使用 $patch 一次性更新避免多次响应；对象式适用于字段明确场景，函数式适用于需读取当前值或条件判断的场景。
Pinia Actions 处理表单提交与状态更新的联动，核心在于把“用户输入 → 状态变更 → 提交逻辑 → 副作用反馈”这一链条收束在单个 action 内，避免分散赋值和重复响应。关键不是写多少 action，而是每个 action 是否承载完整语义、是否控制好更新节奏。
用 $patch 一次性提交表单字段，避免多次触发更新
直接对 state 字段逐个赋值（如 this.name = value; this.email = value;）会触发多次响应式通知。表单通常涉及多个字段，应聚合后统一提交：
- 对象式 $patch：适合字段明确、无依赖关系的场景，例如提交基本信息
this.$patch({ name, email, phone }) - 函数式 $patch：适合需读取当前值或做条件判断的场景，例如追加标签或校验必填项
this.$patch(state => { if (state.tags.length
配合 storeToRefs + 局部表单状态，减少不必要响应
不要在 input change 时就调用 action 或 $patch —— 频繁小更新反而拖慢性能。推荐做法是：
- 组件内用 ref 或 reactive 管理本地表单状态（如 const form = reactive({ name: '', email: '' })）
- 用 storeToRefs 解构需要同步的字段（如 const { stepValid } = storeToRefs(store)），只监听真正影响 UI 的状态
- 在提交或防抖后，再执行 store.$patch(form)，完成一次干净的状态落地
action 返回 Promise，实现提交过程的加载与错误控制
表单提交往往伴随 API 调用，action 必须显式返回 Promise 才能被 await，从而驱动 loading、禁用按钮等 UI 反馈：
- 正确写法：在 action 中 return api.submit(form)，并在 try/finally 中管理 loading 状态
- 避免漏掉 return：如果只写 api.submit(form).then(...) 却没 return 这个 Promise，调用方 await 会立即 resolve undefined
- 可链式处理：返回的数据可直接用于后续逻辑，比如 const result = await store.submitForm(form); router.push('/success')
用 $subscribe 统一处理提交后的副作用
提交成功后常需触发日志、缓存、通知等副作用。若把这些逻辑散落在每个字段更新后，容易重复执行或时机错乱。建议：
- 在 store 初始化时，用 $subscribe 监听 patch 完成事件
- 配合 { detached: true } 实现全局监听，确保只在最终批量更新后执行一次
- 通过 mutation.type 区分是表单提交还是其他更新，避免误触发
