Pinia 结合 TypeScript 规范定义 Store 的核心是 state、getters、actions 全链路可推导、可约束、可维护：state 必须用接口+函数返回并标注类型；getters 按组合式/选项式分情况标注；actions 需参数解构与返回类型明确；推荐组合式 Store 以获更自然类型推导。
Pinia 结合 TypeScript 规范定义 Store，核心是让 state、getters、actions 全链路可推导、可约束、可维护。不靠猜测，而靠接口显式声明和返回类型标注。
state 必须用接口 + 函数返回
不能直接写对象字面量，必须用函数包裹，并标注返回类型接口。这样既保证 SSR 多实例隔离，又让 TS 精准识别结构：
- 定义 UserState 接口，明确字段名、类型、可选性
- state 工厂函数写成
(): UserState => ({ ... }) - 避免
state: { user: null }这类无类型、易污染的写法
getters 类型要分情况标注
组合式 Store 中 getter 用 computed，类型自动推导；选项式 Store 中：
- 箭头函数形式如
total: (state) => state.list.length，TS 通常能自动推导返回值 - 使用
this的 getter（如firstUppercase()），必须手动加返回类型，否则会触发循环推导错误 - getter 内只做同步计算，不发请求、不改状态
actions 参数和 this 上下文都要类型化
action 是状态变更的唯一入口，类型安全直接影响业务健壮性：
- 参数用解构对象传入，比如
login({ email, password }: { email: string; password: string }) - 异步 action 明确返回 Promise 类型，如
async fetchUser(id: number): Promise<void> - 内部
this.xxx赋值时，TS 会基于 state 接口自动校验字段是否存在、类型是否匹配
组合式 Store 更推荐，类型更自然
相比选项式，组合式 Store（defineStore(() => {...})）与 Vue 3 Composition API 风格一致，类型推导更顺滑：
-
ref→ 对应 state，类型通过泛型或赋值自动锁定（如ref<User>({})） -
computed→ 对应 getters，返回值类型由表达式自动确定 - 普通函数 → 对应 actions，参数和逻辑可自由加注解，无需额外泛型
- 所有暴露项必须显式
return，否则组件无法访问且无类型提示
