pinia规范用法是按业务域拆分store、状态与逻辑分离、类型安全优先、所有变更通过action。state声明即冻结，禁止直接修改；用typescript精确约束各部分；优先组合式store，避免继承和过度抽象。

Pinia 的规范用法核心在于模块拆分清晰、状态与逻辑分离、类型安全优先、避免直接修改 state。不追求“炫技”，而是让 store 可读、可测、可复用。

按业务域拆分 Store，不按组件或页面

一个 store 应代表一个明确的业务概念（如 user、cart、notification），而非某个页面（如 homeStore）或组件（如 headerStore）。这样能天然避免状态污染和逻辑耦合。

• ✅ 推荐：useUserStore() 管理登录态、个人信息、权限等全站用户相关逻辑
• ❌ 避免：useHeaderStore() 只为控制 header 显示隐藏——这类 UI 状态应由组件自身 ref 或局部 computed 处理
• 拆分后，多个组件可安全复用同一 store，比如登录页、个人中心、设置页都调用 useUserStore()

State 声明即冻结，只通过 action 修改

Pinia 默认允许直接赋值修改 state，但规范做法是禁止直接写 store.xxx = value，所有变更必须走 action——这是保障可追踪、可调试、可扩展的关键。

• 在 store 定义中，state 返回一个普通对象，不使用 ref 或 reactive 包裹（Pinia 内部已处理）
• 所有数据变更封装进 action：例如 login(credentials)、updateProfile(data)，内部统一调用 this.$patch 或逐字段赋值
• 复杂更新优先用 $patch({ a: 1, b: 2 })；需依赖当前值时，用函数式 $patch(state => { state.count++ })

用 TypeScript 精确约束 State、Getters、Actions

不写类型注解 = 主动放弃 Pinia 最大优势之一。每个 store 都应显式导出接口，并在 defineStore 中标注泛型。

• 定义 interface UserState 和 interface UserGetters，并在 defineStore(...) 中完整声明
• getters 必须返回计算值，不带副作用；若需异步逻辑（如检查 token 是否过期），应放在 action 中，getter 仅做同步派生
• actions 参数建议用对象解构传入，提升可读性与可扩展性：login({ email, password }): Promise<void></void>

组合式 Store 优先，避免过度抽象

Pinia 原生支持组合式 API（defineStore(() => {...})），它比选项式更灵活、更易测试、更利于逻辑复用。

• 把通用逻辑（如请求封装、错误重试）抽成独立 composable 函数，store 中直接调用，而不是塞进 store 的 actions 里
• 避免创建“万能 store”或“baseStore”继承链——Pinia 不鼓励继承，多用组合：比如 useAuthHelpers() 可被 useUserStore 和 useAdminStore 同时引入
• 需要跨 store 协作？用 storeToRefs 解构响应式属性，或在 action 中直接调用其他 store 方法（确保无循环依赖）

Pinia 本身轻量，规范不在框架限制，而在团队共识。从第一个 store 就坚持拆分原则、类型约束和 action 封装，后续维护成本会大幅降低。