Pinia Actions 应封装表单异步提交全流程：输入收集→本地校验→$patch同步→API提交→响应处理；统一管理validation状态、loading、error；action须返回Promise并集成AbortController与API分层。
Pinia Actions 实现表单数据的异步提交与校验，关键在于把“输入收集 → 本地校验 → 状态同步 → 接口提交 → 响应处理”这一完整流程封装进一个 action，避免逻辑分散、状态不一致或重复响应。
用 action 封装完整提交流程
不要在组件中手动逐字段更新 state 或直接调用 API。应在 action 内统一完成：
- 接收表单数据（可来自组件内 reactive 表单对象）
- 执行同步校验（如必填、邮箱格式、密码强度等），失败则提前 return 并设置 error
- 调用 $patch 一次性写入有效字段，避免多次触发响应式更新
- 发起 API 请求，使用 await 等待结果
- 根据响应成功/失败，更新 loading、error、data 等配套状态
校验结果要能全局汇总和响应
分布式校验（比如多步骤表单、子组件各自校验）需统一上报到 store 的 validation 字段中：
- state 中定义 validation: { email: true, password: '密码至少8位', terms: false }
- 提供 getters 如 isValid（全字段为 true）、hasError（任一为 false 或字符串）、errorList（聚合所有提示）
- 通过 action 如 setFieldValidation(field, result) 更新单项，保证 getter 自动重算
提交过程要有加载态与错误反馈
用户需要明确感知操作进行中或失败原因：
- action 内部管理 loading = true → API 调用 → finally 设为 false
- error 字段存用户友好的提示（如 err.response?.data?.message || '网络异常'）
- 组件中用 v-if="store.loading" 控制按钮禁用，v-if="store.error" 显示提示
- action 必须 return Promise，方便组件 await 后跳转或清空表单
配合 API 层与取消机制提升健壮性
真实项目中还需考虑请求可控性和可维护性：
- API 调用必须抽离到 src/api/ 目录下，action 只负责调度，例如 const res = await userApi.submit(form)
- 对搜索类输入、频繁切换页签等场景，在 action 中加入 AbortController，新请求自动终止旧请求
- 用 $onAction({ detached: true }) 全局监听 action 执行，统一打日志、统计耗时、上报错误
