一、问题背景：当Context成为性能瓶颈

我们先看一个真实场景：在React 18项目中，一个复杂的订单管理页面包含订单列表、筛选条件、详情弹窗和操作日志四个模块。最初使用Context管理全局状态，每个模块都通过useContext获取数据。

随着业务迭代，问题逐渐暴露：
- 任何状态更新都会导致Context Provider下的所有组件重新渲染，即使它们只依赖部分数据
- 筛选操作时，整个页面出现明显卡顿，Chrome Performance面板显示单次操作触发超过200次组件渲染
- Props层层传递从到到到，中间组件被迫接收无关数据

在Vue 3项目中，类似的问题通过Provide/Inject也存在，特别是当注入的响应式对象被多个组件修改时，追踪数据流向变得困难。

二、环境与版本：技术栈明细

本次实践的项目环境如下：

{
  "react": "18.2.0",
  "vue": "3.3.4",
  "zustand": "4.4.1",
  "pinia": "2.1.6",
  "typescript": "5.1.6",
  "vite": "4.4.5"
}

项目规模为：
- 组件总数：React项目186个，Vue项目142个
- 全局状态：React项目11个Context，Vue项目8个Provide
- 页面平均状态更新频率：每秒约5次（含轮询和用户交互）

三、方案设计：为什么选择Zustand和Pinia

对比了Redux、MobX、Zustand和Pinia后，我的选择标准是：

学习成本：团队已有React和Vue基础，需要API简洁的方案
性能：需要细粒度的状态订阅，避免无谓重渲染
TypeScript友好度：需要完整的类型推导
中间件支持：需要日志和持久化能力

最终选择：
- React项目使用Zustand，核心优势是create函数直接创建store，通过selector实现按需订阅
- Vue项目使用Pinia，核心优势是与Vue 3的Composition API天然集成，且移除了Vuex的Mutation概念

四、核心实现：迁移步骤与代码示例

4.1 React：从Context到Zustand

第一步：创建Store

// store/orderStore.ts
import { create } from 'zustand';
import { devtools } from 'zustand/middleware';

interface OrderState {
  orders: Order[];
  filter: FilterOptions;
  loading: boolean;
  fetchOrders: () => Promise;
  setFilter: (filter: Partial) => void;
}

export const useOrderStore = create()(
  devtools(
    (set, get) => ({
      orders: [],
      filter: { status: 'all', keyword: '' },
      loading: false,

      fetchOrders: async () => {
        set({ loading: true });
        try {
          const res = await api.getOrders(get().filter);
          set({ orders: res.data });
        } finally {
          set({ loading: false });
        }
      },

      setFilter: (newFilter) => {
        set({ filter: { ...get().filter, ...newFilter } });
        get().fetchOrders();
      },
    }),
    { name: 'order-store' }
  )
);

第二步：替换组件中的Context消费

// 重构前
const { orders, filter } = useContext(OrderContext);

// 重构后 - 按需订阅
const orders = useOrderStore((state) => state.orders);
const filter = useOrderStore((state) => state.filter);
const setFilter = useOrderStore((state) => state.setFilter);

关键点：通过selector只订阅组件依赖的字段。在Zustand中，未使用selector的组件会在任何状态变化时重渲染，这个细节直接决定了性能差异。

4.2 Vue：从Provide/Inject到Pinia

第一步：定义Store

// stores/order.ts
import { defineStore } from 'pinia';

export const useOrderStore = defineStore('order', {
  state: () => ({
    orders: [] as Order[],
    filter: { status: 'all', keyword: '' } as FilterOptions,
    loading: false,
  }),

  getters: {
    filteredOrders: (state) => {
      return state.orders.filter(o => 
        o.status === state.filter.status || state.filter.status === 'all'
      );
    },
  },

  actions: {
    async fetchOrders() {
      this.loading = true;
      try {
        const res = await api.getOrders(this.filter);
        this.orders = res.data;
      } finally {
        this.loading = false;
      }
    },

    setFilter(newFilter: Partial) {
      this.filter = { ...this.filter, ...newFilter };
      this.fetchOrders();
    },
  },
});

第二步：在组件中使用

import { storeToRefs } from 'pinia';
import { useOrderStore } from '@/stores/order';

const orderStore = useOrderStore();
// 使用storeToRefs保持响应性且避免解构丢失
const { orders, filter, loading } = storeToRefs(orderStore);

注意：在Pinia中，直接解构state会丢失响应性，必须使用storeToRefs。这是迁移中最常见的错误之一。

五、踩坑与优化：迁移过程中的真实教训

5.1 React项目踩坑记录

坑1：selector返回新对象导致无限循环

// 错误写法 - 每次返回新对象
const filter = useOrderStore((state) => ({
  status: state.filter.status,
  keyword: state.filter.keyword,
}));

// 正确写法 - 使用浅比较或拆分订阅
const status = useOrderStore((state) => state.filter.status);
const keyword = useOrderStore((state) => state.filter.keyword);

Zustand默认使用Object.is比较selector返回值，如果返回新对象，每次都会触发重渲染。解决方案是使用useShallow或拆分订阅。

坑2：异步action中的状态同步

在fetchOrders中直接调用get().fetchOrders()，但如果在组件卸载后触发更新，会收到警告。需要引入AbortController或检查组件状态。

5.2 Vue项目优化记录

优化1：使用storeToRefs后仍有重渲染问题

排查发现是Pinia 2.x的响应式追踪机制导致的。解决方式是使用markRaw标记非响应式数据，或者确保state中只存放需要响应式的数据。

优化2：批量更新

当需要一次性修改多个state字段时，Pinia中直接多次赋值会触发多次更新。使用$patch可以批量更新：

orderStore.$patch({
  orders: [...],
  loading: false,
});

六、效果数据：迁移前后的性能对比

使用React Profiler和Vue Devtools进行测量，数据如下：

指标 Context/Provide Zustand/Pinia 提升幅度
筛选操作触发渲染次数 214次 37次 -82.7%
页面交互响应时间 120ms 40ms -66.7%
首屏加载时间（含状态初始化） 1.8s 1.5s -16.7%
代码中Props传递层数 平均4.2层 平均1.8层 -57.1%
新增业务功能平均开发时长 3.5小时 1.8小时 -48.6%

在React项目中，迁移后App包体积减少了22kB（主要是移除了大量Context Provider嵌套代码），Vue项目减少了15kB。

七、总结：何时应该迁移到状态管理库

经过这次实践，我的判断标准是：

需要迁移的信号：
- Context Provider嵌套超过3层
- 单次状态更新触发超过50个组件重渲染
- Props传递需要经过中间组件
- 需要持久化、日志等中间件支持

不必迁移的场景：
- 小型项目，状态量少且更新频率低
- 状态仅在一个组件内部共享
- 团队对现有方案熟悉且没有明显性能问题

最后强调：状态管理库不是银弹，它解决的是“状态共享和更新效率”问题。如果项目还在初创阶段，先用Context/Props保持简单；当问题真实出现时，再迁移也不迟。关键是识别到瓶颈的那一刻，就要果断行动，避免技术债越积越重。