状态管理该用哪个?
在 Vue 3 新项目中,优先选择 Pinia。它是 Vue 官方推荐的状态管理库,API 更贴近 Composition API,TypeScript 类型推导也更自然。
Vuex 并不是“不能用”:Vuex 4 仍适合已经大量使用 Vuex 的 Vue 3 老项目。迁移的收益主要在开发体验和类型安全,不必为了换库而一次性重写整个项目。
commit/dispatch 通常需要分别声明。这些是 Vuex 的使用成本,不代表它的响应式、插件机制或严格模式失效;已有项目继续维护 Vuex 是合理的。
Pinia 既支持 Composition API,也支持 Options API:
defineStore 推导 State、Getters 和 Actions 的类型,减少字符串路径和手动声明。ref、computed 和普通函数组织复杂业务逻辑。“体积小于 1KB”不建议作为固定结论:实际产物会受版本、构建方式和依赖压缩影响。比较时应以项目构建后的 bundle 分析为准。
| 需求 | Vuex | Pinia |
|---|---|---|
| 定义状态 | state | state 或 ref |
| 派生状态 | getters | getters 或 computed |
| 修改状态 | commit Mutation | 直接修改或调用 Action |
| 业务逻辑/异步 | dispatch Action | Action(支持同步/异步) |
| 模块拆分 | modules、命名空间 | 多个 defineStore |
Pinia 取消 Mutations 并不等于“任何地方都随意改状态”。复杂变更仍建议集中到 Action 中,这样更容易复用、测试和追踪;简单表单状态则可以直接赋值。
mapState、mapActions、commit、dispatch 需要改成 Store 实例的属性访问和方法调用。ref/reactive,跨层传递用 provide/inject,通常更简单。| Vuex | Pinia | |
|---|---|---|
| API | 偏集中式,样板较多 | 更直接 |
| Mutations | 有 | 无 |
| TypeScript | 使用成本较高 | 类型推导友好 |
| Store | modules 集中管理 | 多个独立 Store |
| SSR | 支持 | 支持,需按请求隔离实例 |
| 适合 | 存量 Vuex 项目 | Vue 3 新项目 |
一句话回答:新项目用 Pinia,老项目不必为了“换成 Pinia”而重写;是否迁移取决于类型安全、维护成本和改造收益。