Pinia Actions 在 TypeScript 中需显式标注参数与返回值类型：参数必标（基础类型直写、对象用接口）、异步返回值须标 Promise<T>、state 类型要明确以保障 this 类型安全、跨 store 调用需类型对齐。
Pinia 的 Actions 在 TypeScript 下要真正安全、可维护，关键不是“能不能标”，而是“在哪标、标什么、为什么必须标”。自动推导覆盖大部分场景，但核心边界必须人工干预。
参数类型必须显式标注
Actions 的入参不标注类型，TS 会默认为 any，失去校验意义。尤其当参数是对象或复杂结构时，漏标等于放行所有错误数据。
- 基础类型直接写：如
increment(step: number)、setName(name: string) - 对象参数优先用接口：定义
interface UserForm { name: string; email?: string }，再写createUser(form: UserForm) - 避免
any或object：它们绕过类型检查，后续调用form.xxx不报错，但运行时可能崩溃
返回值类型建议显式标注（尤其异步）
同步 action 的返回值 TS 通常能推导，但异步 action 必须标 Promise<T>，否则调用方无法感知 await 后的数据结构。
- 写
async fetchUser(id: number): Promise<UserInfo>，组件里const user = await store.fetchUser(123)才能获得user.name的提示和校验 - 即使只做副作用（如提交表单后无返回），也建议写
submitForm(data: Form): Promise<void>，明确语义 - 不要依赖自动推导
Promise<unknown>，它会让后续链式操作失去类型保护
内部 this 的类型由 state 决定，但需保持一致
Actions 中的 this 指向当前 store 实例，其类型由 state 返回值决定。如果 state 类型模糊，this 就不可靠。
- state 必须用接口或明确返回类型注解，例如
state: (): CounterState => ({ count: 0 }) - 这样
this.count才是number，this.count.toFixed()才不会报错 - 若 state 是
{ count: 0 as any }，则this.count是any，整个 action 失去类型约束
跨 store 调用也要类型对齐
一个 action 里调用另一个 store 的方法，比如 userStore.login() 之后触发 cartStore.syncCart()，两者的参数和返回值都需类型匹配。
- 确保被调用 store 的 actions 已正确标注类型，否则
cartStore.syncCart()可能接受任意参数 - 推荐在调用前加类型断言或使用泛型工具函数，避免隐式
any渗透 - 大型项目建议统一定义共享 payload 接口（如
LoginPayload），多个 store 共用，减少重复和不一致
