Pinia 的 state 必须为返回 plain object 的函数以确保响应性和 SSR 支持,actions 是修改 state 的唯一推荐方式,选项式与组合式 store 行为一致但风格不同,需避免副作用和 ref 嵌套等误区。

Pinia 中的 state 就是响应式数据的源头,它天然具备 Vue 3 的响应性,不需要额外用 ref 或 reactive 包裹 —— 只要按规范定义,内部所有属性都会自动响应。
State 必须用函数返回对象
state 必须写成箭头函数或普通函数,返回一个 plain object。这是为了确保每次调用 store 时都获得独立的状态副本(尤其在 SSR 场景中)。
- ✅ 正确写法:
state: () => ({ count: 0, list: [], user: null }) - ❌ 错误写法:
state: { count: 0 }(会报错,且无法服务端渲染) - ⚠️ 注意:嵌套对象、数组、null、undefined 都能响应,但不能直接用
ref或computed返回 —— 它们本身不是响应式“源”,而是响应式“产物”
Actions 是修改 state 的唯一推荐方式
所有对 state 的变更都应通过 actions 进行,这样便于追踪、调试、复用逻辑,也兼容异步流程。
审查 Vue 管理后台的变更请求(Vue 2 + Element UI,Vue 3 + Element Plus)。重点关注最小化变更实现、上线风险检查以及回归检查清单生成。
- 同步修改直接赋值:
this.count++或this.items.push(item) - 异步操作中先置状态再更新:
this.loading = true→ 请求 →this.data = result→this.loading = false - 不建议在组件中直接改
store.count = 5,虽可行但绕过逻辑封装,不利于维护
两种 Store 写法对应不同的 state/actio ns 组织风格
选项式(Options Store)更直观,适合初学或结构清晰的模块;组合式(Setup Store)更贴近 Composition API 风格,适合需要精细控制响应式依赖的场景。
立即学习“前端免费学习笔记(深入)”;
- 选项式:
state返回对象,actions是方法对象,内部用this访问 state - 组合式:
defineStore直接返回解构后的ref/computed/function,state 属性需显式声明为ref,actions 是普通函数 - 两者最终生成的 store 实例行为一致,响应性无差别
避免常见误区
有些写法看似省事,实则破坏响应性或引发意外行为。
- 不要在 state 函数里调用 API 或产生副作用(如
state: () => ({ now: Date.now() })),这会导致每次实例化都执行一次 - 不要把整个
ref对象作为 state 属性(如count: ref(0)),Pinia 会自动解包 ref,反而造成冗余和类型混乱 - actions 里修改 state 不需要
return,也不用emit或dispatch—— 赋值即触发响应更新

















