pinia 状态验证需在变更前通过 actions 封装校验逻辑，结合 typescript 类型约束与运行时判断，支持必填字段、数值范围、格式正则及业务规则检查，并可抽离为独立函数或通过插件统一注入。
给 Pinia 状态添加自定义验证逻辑，核心是在状态变更前做校验，而不是等数据进入 state 后再处理。它不依赖外部库，而是通过 actions 封装校验步骤，结合 TypeScript 类型约束和运行时判断，实现可靠的数据守门。
在 actions 中嵌入验证判断
Pinia 没有内置的 validation middleware，但允许你在每个修改状态的 action 内部主动检查输入参数和当前状态。这是最直接、可控的方式。
- 验证必填字段是否缺失，比如 id、email、price
- 检查数值范围，例如 age 是否在 0–120 之间，quantity 是否大于 0
- 对格式敏感的数据（如邮箱、手机号）做正则校验，避免存入非法字符串
- 验证前后状态逻辑一致性，比如“已支付订单不能重复支付”这类业务规则
用 $patch 配合前置校验函数
当批量更新多个字段时，推荐先写一个校验函数，再调用 $patch。这样既保持代码清晰，又避免重复逻辑。
- 把校验逻辑抽离为独立函数（如 validateUserProfile），接收待更新对象作为参数
- 校验失败时抛出错误或返回 false，并在 action 中统一处理（提示用户 / 中断执行）
- 只在验证通过后才执行 this.$patch(newData)，确保 state 始终合法
结合 TypeScript 接口 + 运行时双重防护
TypeScript 能在开发期拦截类型错误，但无法覆盖所有运行时场景（比如后端返回空字符串、用户粘贴异常文本）。所以需要两者配合：
- 用 interface 定义 state 结构，强制字段类型（id: number、email: string）
- 在 action 中补充运行时检查：例如 typeof item.id === 'number' && item.id > 0
- 对可选字段（如 age?: number）明确约定 null/undefined 的语义，避免后续逻辑误判
用插件统一注入验证能力（进阶）
若多个 store 需要相似验证规则（如所有表单类 store 都要防空提交），可通过 Pinia 插件注入通用校验方法：
- 插件中向 store 添加 $validate 方法，接收 schema 或校验配置
- 在 action 内部调用 this.$validate(payload, rules)，复用逻辑
- 适合中大型项目，避免每个 store 重复写 if 判断
