pinia action 参数应统一为对象结构并用 typescript 接口约束类型。推荐使用语义化输入对象（如 createuserinput）、共用类型抽象（如 listquery），避免零散参数和内部转换，确保意图明确、可扩展、强校验。
Pinia 的 action 参数处理，关键在于**明确意图、约束类型、避免隐式耦合**。不建议让 action 直接接收一堆零散参数，而应根据用途统一设计输入结构——要么用对象解构，要么用接口封装，同时配合 TypeScript 实现静态校验。
按业务语义封装为单个对象参数
多数场景下，action 接收的参数天然属于同一业务上下文（如创建用户、更新配置、分页查询），此时应合并为一个对象，而非多个独立参数。
- 清晰表达意图：比如 fetchPosts({ page: 1, size: 10, keyword: '' }) 比 fetchPosts(1, 10, '') 更易读、更易扩展
- 支持可选字段：对象天然支持部分属性缺失，便于默认值处理和向后兼容
- 方便类型定义：可直接关联 interface 或 type，IDE 补全和错误提示更准
用 TypeScript 接口明确定义输入结构
在 store 文件中为每个关键 action 声明专用输入类型，强制约束字段名、类型和是否必填。
- 示例：interface CreateUserInput { name: string; email: string; role?: 'user' | 'admin' }
- action 签名写成：async createUser(input: CreateUserInput): Promise
- 调用时 IDE 会提示必填项，传错类型立即报错，不依赖运行时校验
对高频复用参数做顶层抽象（如分页、筛选）
当多个 action 都涉及分页、排序或通用筛选逻辑，可提取共用类型，减少重复定义。
- 例如定义 type ListQuery = { page?: number; size?: number; sort?: string; q?: string }
- 多个 action 共享该结构：fetchUsers(query: ListQuery)、searchProducts(query: ListQuery)
- 后续加字段（如 status?: 'active' | 'inactive'）只需改一处
避免在 action 内部做复杂参数转换
参数应在调用方就组织好，action 只负责“接收并使用”。不要让 action 承担格式适配职责。
- ❌ 错误做法：组件传入 id: string，action 里手动 parseInt(id)
- ✅ 正确做法：组件确保传 id: number，或 action 接收 { id: number } 并由 TypeScript 报错拦截非法输入
- 若确实需容错（如 URL 参数是字符串），应在 API 层或 service 层转换，而非 action
