第 6 章 状态管理：共享数据的仓库

第 6 章 · 状态管理：共享数据的仓库

章节摘要：当共享状态散落在组件树各处，通信链路开始腐烂，状态管理仓库把它集中到单例。本章从 Vuex 的 state/getters/mutations/actions 讲到模块化拆分，再到新一代标准 Pinia——为什么它更简单、以及迁移的判断。

学习目标

阅读完本章，你应当能够：

1. 说清"什么时候真的需要状态管理"，避免为了用而用；
2. 按 Vuex 四件套的职责分工写出规范 store；
3. 用 modules 拆分大 store 并理解命名空间；
4. 用 Pinia 写出更精简的等价实现并说明其优势来源。

核心概念速览

仓库的本质：把状态从组件树里搬出来，放进一个响应式单例——数据还是那套响应式系统，只是主人换了。

子章节导航

6.1 Vuex 核心概念

state、getters、mutations、actions 四件套的职责与同步/异步的红线。

6.2 模块化与 Pinia

大 store 的 modules 拆分、命名空间坑，以及 Pinia 如何用更少的概念做同样的事。

子章节之间的逻辑关系

6.1 立 Vuex 的世界观（状态变更必须走 mutation 的单行道），6.2 先解决它长胖之后的问题（模块化），再给出替代方案（Pinia）——后者在概念上是前者的减法。

共享状态需求
   → Vuex 四件套（6.1）
        → 项目变大 → modules 模块化（6.2）
        → 新项目 → Pinia：去掉 mutations 与根实例（6.2）
​

前置知识与后续延伸

• 前置：第 2 章响应式系统（仓库的更新通知完全复用它）、第 5 章通信阶梯（仓库是阶梯顶层）；
• 为后续铺路：第 7 章路由守卫里常见"读仓库状态做权限判断"，第 10 章组合式 API 与 Pinia 的配合是现代 Vue 的标准搭配。

一个判断读者是否真正理解本章的小问题：仓库里的状态变了，远处的组件是怎么知道的？如果答案是"因为用了 Vuex"，说明还停留在名词层；正确答案是——仓库的 state 本身就是第 2 章讲的响应式对象，组件读取它时同样发生依赖登记，变更时同样走派发更新，Vuex 与 Pinia 只是提供了集中存放与规范变更路径的外壳。想通了这一层，你对"仓库要不要用、用了会不会慢"这类问题就都有了判断依据，而不是人云亦云。