后来 Pinia 出来了。一开始我以为只是又一个“下一代状态管理”的噱头，直到我用一个下午把一个老模块从 Vuex 重写到 Pinia。代码从 行缩到 行，类型提示丝滑得像 VSCode 开了挂。那一刻我懂了这方面，不是 Pinia 太新。而是 Vuex 太老了。

这篇文章不会跟你念文档，我想用一个真实的对比场景 —— 一个“使用者偏好设置”模块—— 来告诉你。Pinia 到底好在哪，还有为什么官方团队钦定 Pinia 为 Vue 的默认状态管理方案。

一、Vuex 的痛，从“仪式感”变成“仪式病”

我们先用 Vuex 实现一个典型的 userPrefs 模块。

export default { namespaced: true,state: =>,getters: { isDarkMode: => state.me === 'dark',currentLanguage: => state.language。},mutations: { SETTHEME { state.me = me },SETLANGUAGE { state.language = lang },TOGGLE_SIDEBAR { state.sidebarCollapsed =!state.sidebarCollapsed },},actions: { changeTheme { // 这里可以调用 API 存后端 localStorage.setItem commit },changeLanguage { localStorage.setItem commit },toggleSidebar { commit },}。}

接下来在组件里使用：

看起来还行？等一等，问题藏在细节里：

. 四个“仪式”动作。心智负担高

每加一个状态，就得手动维护四个位置。写 mutation 时你问自己：这个真的需要 mutation 吗？再看——答案是，Vuex 要求你写，哪怕它只是同步赋值。说起来，

. TypeScript 推导 ≈ 不存在

mapState 返回的是 any你永远不知道 this.me 到底是不是 string。除非你手动给模块加类型声明。接下来写一堆 RootState 接口，再接下来…，算了改喝咖啡吧。

. 命名空间是“手动挡”

你忘了加 namespaced: true？全家桶污染，你写了带命名空间的 dispatch?字符串容易写错，IDE 帮不了你。

. 代码组织撕裂

同一个“偏好设置”的逻辑，状态写这里mutations 写那里actions 又跑到了下面。 如果模块再大一点，你得上下滚动三百行才能改完一个功能。这就是 Vuex 的“仪式病”——它把原本简单的数据更新，强行套上了一个基于 Flux 的严肃架构 。放在 年很先进，放在 年，就像还在用 jQuery 写动画一样。

二、Pinia：少即是多，但不少功能

Pinia 的设计哲学一句话就能概括：把 store 写得像你手写的一个普通组合式函数 。但自动帮你做响应式、DevTools 追踪、插件 一样一个 userPrefs 模块，用 Pinia 怎么写？

import { defineStore } from 'pinia' import { ref,computed } from 'vue' export const useUserPrefsStore = defineStore => { // state —— 就是 ref / reactive const me = ref const language = ref const sidebarCollapsed = ref // getters —— 就是 computed const isDarkMode = computed => me.value === 'dark') // actions —— 就是普通 function。可以异步 function changeTheme { me.value = newTheme localStorage.setItem } function changeLanguage { language.value = lang localStorage.setItem } function toggleSidebar { sidebarCollapsed.value =!sidebarCollapsed.value } // 把要暴露的东西 return 出去 return { me,language,sidebarCollapsed,isDarkMode。changeTheme,changeLanguage,toggleSidebar,} }) 

&# x3C;不过，template> &# x3C;div :class="{ dark: userPrefs.isDarkMode }"> &# x3C;button @click="userPrefs.changeTheme">亮色模式 &# x3C;/button> &# x3C;/div> &# x3C;/template> &# x3C;不过，script setup> import { useUserPrefsStore } from '@/stores/userPrefs' const userPrefs = useUserPrefsStore // 直接解构也不会丢失响应式 &# x3C;其实，/script>

光是视觉上，Pinia 就赢了——它没有 mutation。没有命名空间字符串，没有 map 辅助函数 . 更关键的是你的 store 就是一个普通函数，里面能用 Vue 的所有响应式 API。老实说，

对比表

mutations : {  SET_USER {   state .user = user },},actions :  {  commit },},
这样不仅代码更多，而且类型推导也会变差。

Pinia 直接允许你修改 state 
中的
ref
不仅代码更少，而且普通赋值也能被 DevTools 记录 
—— 因为 Pinia 基于 Vue
的响应式程序实现。
// 直接改 ，userPrefs .me= 'light'

// 或者封装成方法
 userPrefs . changeTheme 


这样不仅简化了代码，还保留了调试能力。