Pinia 状态管理

状态：未准备
适用方向：前端 / Go 全栈
最近复习：待填写
下次复习：待安排

一句话回答

Pinia 管理跨组件共享的响应式状态，提供 state、getter、action 和工具支持；局部交互不必全局化，持久化、请求缓存和服务端权限仍需额外设计。

原理解释

Option Store 与 Setup Store

Option Store 用 state/getters/actions 声明，结构直观；Setup Store 用函数返回 ref、computed 和函数，便于组合。Setup Store 中应返回需被 Pinia 管理的状态，随意隐藏状态会影响 SSR、DevTools 和插件等能力。

// stores/counter.ts
import { defineStore } from 'pinia'

export const useCounterStore = defineStore('counter', {
  state: () => ({ count: 0 }),
  getters: {
    double: state => state.count * 2,
  },
  actions: {
    increment() { this.count++ },
  },
})

// 组件 setup 中；应用已 app.use(createPinia())。
import { storeToRefs } from 'pinia'
import { useCounterStore } from './stores/counter'

const counter = useCounterStore()
const { count, double } = storeToRefs(counter)
const { increment } = counter

store 是响应式对象，直接解构 state/getter 通常会失去属性的响应式联系；storeToRefs 专门提取响应式状态和 getter，跳过 action 等非响应式成员。action 可直接解构使用。调用 useCounterStore 通常取得当前 Pinia 实例中的同一个 store，而不是每个组件新建一份局部状态。

更新与重置

可以直接改状态，也可以用 $patch 组织批量修改；action 集中业务意图并可异步执行。Option Store 提供 $reset 重建初始 state；Setup Store 需自行实现重置。不要把所有 store 都无差别重置，需按登录态、业务缓存和页面状态区分职责。

场景与边界

Pinia 内存状态在刷新后不会自动保存，持久化需自己实现或使用插件，并处理版本迁移、过期、错误与隐私。token 放入 localStorage 仍受 XSS 风险影响；恢复出用户对象不等于当前会话有效。

SSR 中要为请求正确创建与关联 Pinia 实例，不能把用户状态作为进程级单例复用；序列化状态时防止注入与秘密泄露。登录退出、切换账号时应清理对应用户的数据，避免不同用户看到彼此缓存。

与 Vuex 对比时，可说明 Pinia 不要求 mutation 层、支持独立 store 与类型推导；不要把“少了 mutation”解释成“不需要统一更新约束”。团队仍可把重要业务变更集中到 action。

项目中的应用

现有 EinoTalk 的 Zustand store 可作为迁移练习：把认证、聊天、UI 按职责拆成 Pinia store，设计退出清理与消息归属。这里只做学习映射，未实际替换仓库的状态库。

常见追问

什么时候用 Pinia 而非 props？ 多个较远组件共享、状态生命周期跨页面或需要集中业务维护时；局部组件状态仍就近保存。
getter 能请求接口吗？ 派生 getter 应保持纯净，请求放 action 或专门的数据层。
有全局 store 就无需请求缓存库吗？ 不一定，请求去重、失效、重试、分页和竞态仍需明确实现。

Pinia 状态管理 ​

一句话回答 ​

原理解释 ​

Option Store 与 Setup Store ​

更新与重置 ​

场景与边界 ​

项目中的应用 ​

常见追问 ​

参考资料 ​