# Pinia 3+ 时代：别再把 Store 当成“全局变量”用了

![image](https://developer.qcloudimg.com/http-save/yehe-1209475/29fec63b5f2125c6c665c58e30665743.png)

## 前言

你好，我是喵喵侠，是一名前端开发。

在 Vue 2 时代，我们受限于 Vuex 的 `mutations`​ 规范，虽然写起来繁琐，但代码的预期性很高。到了 2026 年，Pinia 已经完全统治了 Vue 生态。由于它的 API 极其精简，甚至允许在组件中直接修改 `state`，这导致很多开发者开始放飞自我。

我最近在处理几个大中型项目的架构迁移时发现，Store 往往变成了开发者逃避 `props`​ 传递的“避风港”：只要是跨两层的变量就往 Store 里扔，只要是异步请求就封装成 `actions`。这种把 Store 当成“增强版全局变量”的做法，不仅会导致逻辑严重耦合，还会让后续的维护和自动化测试变得极其困难。

本文将从架构设计、逻辑组织、插件扩展以及测试方案四个维度，分享如何构建一个工程化、可维护的 Pinia 状态层。

## 架构思维：从中心化到领域驱动

Pinia 与 Vuex 最大的区别在于它不再有一个全局唯一的 `Root Store`。这种去中心化的设计要求我们必须具备领域模型意识。

#### 1. 领域驱动设计 (Domain-Driven Design)

在大型项目中，不要按照功能（如 `loadingStore`​, `errorStore`​）来拆分，而要按照业务领域拆分。例如 `useUserStore`​ 应该只包含用户自身的属性和权限；`useOrderStore`​ 只包含订单流转逻辑。如果一个变量不属于任何特定的业务领域，它可能应该存在于组件的 `ref` 中，而不是全局 Store。

#### 2. UI 状态与业务状态的分离

这是一个常见的误区。很多开发者把侧边栏是否折叠、弹窗是否显示这类纯 UI 状态也塞进业务 Store 里。这会导致业务逻辑被 UI 细节污染。正确的做法是建立专门的 `useAppPreferenceStore` 来处理 UI 偏好，让业务 Store 保持纯净的 Data 处理逻辑。

#### 3. 避免“万能 Store”的坍塌

当一个 Store 的行数超过 500 行时，它就变成了一个难以理解的黑盒。即便 Pinia 支持去中心化，我们依然要警惕“巨石 Store”的出现。如果发现某个 Store 承载了太多的职责，应果断通过组合式函数（Composables）将其内部逻辑进一步抽离。

## Setup 还是 Option？

在 `defineStore` 的定义方式上，我始终坚持在复杂业务中使用 Setup 模式。

#### 1. 逻辑组合与封装能力

Setup 风格（传入一个函数）允许我们在 Store 内部使用所有的 Composition API 能量。这种能力在处理跨逻辑联动时非常强大。

```javascript
export const useAuthStore = defineStore('auth', () => {
  const token = ref(localStorage.getItem('token') || '');
  
  // 可以在 Store 内部直接使用 watch 联动，实现数据持久化或副作用处理
  watch(token, (newToken) => {
    if (newToken) {
      api.defaults.headers.common['Authorization'] = `Bearer ${newToken}`;
    }
  });

  return { token };
});
```

#### 2. 天然的类型推导

在 TypeScript 环境下，Setup 风格的类型推导是原生的。你不需要像 Option 风格那样通过 `this` 来访问状态，所有变量、计算属性和函数都会被 TS 编译器完美识别，极大减少了开发时的类型断言操作。

#### 3. 更好的代码组织结构

在 Setup 模式下，你可以按照逻辑块来组织代码，而不是被强行分割在 `state`​、`getters`​ 和 `actions` 三个固定的属性里。这使得代码的阅读体验更接近于普通的业务函数，降低了心智负担。

## 跨 Store 的协同技巧

由于 Pinia 是网状结构，Store 之间的依赖管理是工程化的难点。

#### 1. 解决循环依赖

Store A 依赖 Store B，Store B 又依赖 Store A，这是导致应用启动失败的常见原因。为了规避这一点，我推荐在 Actions 内部进行动态引入。

```javascript
export const useCartStore = defineStore('cart', () => {
  function checkout() {
    // 动态调用，避免顶层循环依赖导致的初始化顺序问题
    const userStore = useUserStore(); 
    if (!userStore.isLoggedIn) {
      return '/login';
    }
    // ... 执行结算逻辑
  }

  return { checkout };
});
```

#### 2. 提取公共逻辑到第三方 Store

如果发现多个 Store 都在使用同一套复杂的过滤逻辑或格式化算法，不要在各处重复写。应该提取出一个专门的“计算 Store”或者无状态的外部工具函数。

#### 3. 显式的依赖注入

在一些高级场景下，我们可以通过参数化的方式将一个 Store 的实例传递给另一个 Store 的 Action。这种显式的传递虽然增加了代码量，但在进行复杂业务追溯和单元测试时，逻辑流向会非常清晰。

## 进阶：利用插件系统实现自动化

不要在每个 Store 里手动去写 `localStorage.setItem`，这在 2026 年属于低效操作。

#### 1. 实现声明式持久化

通过自定义插件，我们可以根据 Store 的配置项自动处理数据恢复和存储。

```javascript
const myPersistPlugin = ({ store }) => {
  // 从自定义配置中读取是否需要持久化
  if (store.$options.persist) {
    const savedState = localStorage.getItem(`pinia-${store.$id}`);
    if (savedState) {
      store.$patch(JSON.parse(savedState));
    }

    store.$subscribe((mutation, state) => {
      localStorage.setItem(`pinia-${store.$id}`, JSON.stringify(state));
    });
  }
};
```

#### 2. 全局状态变更监控

在开发环境下，我们可以编写插件来记录每一次 `action`​ 的调用耗时和参数。这比单纯查看 `vue-devtools` 更有助于发现性能瓶颈，尤其是在处理高频触发的状态变更时。

#### 3. 扩展全局属性

利用 `pinia.use()`​，我们可以向所有的 Store 注入一些全局实例，比如路由对象、API 请求封装或者国际化工具，避免在每个文件里重复 `import`。

## 极致的变更控制与性能

Pinia 的灵活是双刃剑，不加克制的修改会导致响应式系统的灾难。

#### 1. 坚持使用 Actions 修改状态

虽然 Pinia 允许你在组件里直接写 `userStore.name = 'miao'`，但我强烈建议禁止这种行为。所有的状态变更都应该封装在 Actions 中。这样当你需要追踪“谁改了这个值”或者需要在修改前加入逻辑校验时，只需在 Action 里统一处理。

#### 2. 利用 \$patch 减少渲染开销

如果你需要一次性修改 State 中的多个字段，直接赋值会触发多次订阅更新。使用 `$patch` 传入一个函数，Pinia 会将这些更改合并。

```javascript
userStore.$patch((state) => {
  state.name = '喵喵侠';
  state.age = 18;
  state.lastLogin = Date.now();
});
```

#### 3. 状态的只读保护

在一些核心 Store 中，我们可以通过 `computed`​ 暴露状态，而将真实的 `ref` 隐藏在闭包中。这样可以从语言层面强制要求调用者必须使用 Actions，从而实现数据的单向流转。

## 单元测试实战

一个不具备可测试性的 Store 是不可靠的。

#### 1. 环境沙箱化

利用 `setActivePinia`，我们可以确保每个测试用例运行时都拥有一个干净、隔离的 Pinia 实例。

```javascript
import { setActivePinia, createPinia } from 'pinia';
import { useCounterStore } from './counter';

describe('Counter Store', () => {
  beforeEach(() => {
    // 每次测试前重置 Pinia 状态，避免测试用例间的干扰
    setActivePinia(createPinia());
  });

  it('increments', () => {
    const counter = useCounterStore();
    counter.increment();
    expect(counter.count).toBe(1);
  });
});
```

#### 2. 模拟外部依赖 (Mocking)

当 Store 依赖于 API 请求时，我们不应该发起真实请求。使用 Vitest 等工具 mock 掉 API 层，我们只需要验证 Store 在接收到特定结果后，其内部状态是否演进正确。

#### 3. 测试订阅行为

通过模拟 `store.$subscribe` 的触发，我们可以测试持久化逻辑或与其他模块的联动是否按预期执行。这在处理跨模块通信时尤为重要。

## 总结

Pinia 3+ 赋予了我们极大的开发自由度，但这种自由应该建立在严谨的工程规范之上。在 2026 年的项目开发中，优秀的 Store 应该是职责明确、逻辑内聚、且能够脱离 UI 组件独立运行的。通过 Setup 模式提升逻辑封装、利用插件系统处理横切关注点、并严格遵守 Actions 变更规范，你的状态层才能真正成为应用的“大脑”，而不是一团乱麻的全局变量。


在 Vue 2 时代，我们受限于 Vuex 的 mutations​ 规范，虽然写起来繁琐，但代码的预期性很高。到了 2026 年，Pinia 已经完全统治了 Vue 生态。由于它的 API 极其精简，甚至允许在组件中直接修改 state，这导致很多开发者开始放飞自我。

Pinia 3+ 时代：别再把 Store 当成“全局变量”用了

前端

Pinia3+状态管理最佳实践：避免Store沦为全局变量，采用领域驱动设计分离业务与UI状态，使用Setup模式提升代码组织性，通过插件实现自动化持久化，严格遵循Actions变更规范确保可维护性。掌握跨Store协同技巧和单元测试方法，构建工程化Vue状态层。

数据恢复

单元测试

TypeScript

编译器

路由

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Pinia 3+ 时代：别再把 Store 当成“全局变量”用了-腾讯云开发者社区-腾讯云

Pinia 3+ 时代：别再把 Store 当成“全局变量”用了

Pinia 3+ 时代：别再把 Store 当成“全局变量”用了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐