1. 问题背景：当Context/Props成为性能瓶颈

2023年接手一个用了3年的后台管理系统，前端技术栈混乱：老模块用Vue 2 + Vuex，新模块用React 16 + Context API。业务逻辑集中在“工单管理”模块，状态包含：用户信息、工单列表、筛选条件、分页参数、操作日志——所有数据都挂在根组件的state里，通过props层层传递，深度达到7层。

痛点数据：
- 每次分页切换触发32个组件重渲染，控制台React DevTools显示“Profiler”火焰图一片红
- Vue 2的provide/inject虽然避免props传递，但依赖注入的响应式对象更新时，所有子组件都会重新计算computed
- 一个表单输入框的onChange事件，因为Context的value变化导致整个树重新渲染，页面卡顿从300ms到1s不等

性能瓶颈根因：Context/Props的更新粒度是“组件树级别”，而非“状态订阅级别”。状态管理库通过发布-订阅模式，让只有订阅了具体状态的组件才重新渲染。

2. 环境与版本：双栈统一前的技术选型

项目 旧技术栈 新技术栈
React模块 React 16.14 + Context API React 18.2 + Zustand 4.5
Vue模块 Vue 2.7 + Vuex 3.6 Vue 3.4 + Pinia 2.1
构建工具 Webpack 4 Vite 5.0 (React) / Vite 4.5 (Vue)
性能工具 React Profiler Chrome Performance + React Scan

选择Zustand的原因：API简洁（无Provider包裹），支持slice模式拆分状态，内置React 18的useSyncExternalStore适配。Pinia则是Vue 3官方推荐，天然支持Composition API和TypeScript。

3. 方案设计：从全量Context到分片Store

核心设计原则：
- 状态分片：将全局状态按业务模块拆成多个store（userStore、ticketStore、filterStore）
- 选择性订阅：组件只订阅自己需要的状态字段，不订阅整个store
- 不可变更新：Zustand的set函数默认浅合并，强制使用不可变模式

以React模块的“工单列表”为例，旧Context结构：

// 旧的Context方案（问题代码）
const AppContext = React.createContext();

function AppProvider({ children }) {
  const [state, setState] = useState({
    user: null,
    tickets: [],
    filters: { status: '', priority: '' },
    pagination: { page: 1, pageSize: 20 },
    loading: false,
    logs: []
  });

  const fetchTickets = async (filters) => {
    setState(s => ({ ...s, loading: true }));
    const res = await api.getTickets(filters);
    setState(s => ({ ...s, tickets: res.data, loading: false }));
  };

  return (

      {children}

  );
}

重构后的Zustand store：

// 新的Zustand方案（优化代码）
import { create } from 'zustand';
import { devtools, subscribeWithSelector } from 'zustand/middleware';

// 工单store - 只关注工单相关状态
const useTicketStore = create(
  subscribeWithSelector(
    devtools(
      (set, get) => ({
        tickets: [],
        loading: false,
        error: null,

        // 使用slice模式，只更新tickets字段
        setTickets: (tickets) => set({ tickets }, false, 'tickets/set'),

        fetchTickets: async (filters) => {
          set({ loading: true, error: null }, false, 'tickets/fetchStart');
          try {
            const res = await api.getTickets(filters);
            // 关键：只更新tickets和loading，不影响user和logs
            set({ tickets: res.data, loading: false }, false, 'tickets/fetchSuccess');
          } catch (err) {
            set({ error: err.message, loading: false }, false, 'tickets/fetchError');
          }
        },

        // 使用get()读取其他store，避免循环依赖
        clearTickets: () => {
          const { filters } = useFilterStore.getState();
          set({ tickets: [], loading: false });
        }
      }),
      { name: 'ticket-store' }
    )
  )
);

Pinia的Vue 3版本类似：

// Vue 3 + Pinia store
import { defineStore } from 'pinia';

export const useTicketStore = defineStore('ticket', {
  state: () => ({
    tickets: [] as Ticket[],
    loading: false,
    error: null as string | null
  }),
  actions: {
    async fetchTickets(filters: FilterParams) {
      this.loading = true;
      this.error = null;
      try {
        const res = await api.getTickets(filters);
        this.tickets = res.data;
      } catch (err: any) {
        this.error = err.message;
      } finally {
        this.loading = false;
      }
    }
  },
  // getters实现派生状态，避免重复计算
  getters: {
    ticketCount: (state) => state.tickets.length,
    hasError: (state) => state.error !== null
  }
});

4. 核心实现：迁移步骤与关键代码

步骤1：渐进式替换，不一次性重构

先抽取一个独立的store（如userStore），将用户信息从Context中剥离。组件中使用zustand的shallow比较器实现选择性订阅：

// 组件只订阅user.name，user.info变更不触发重渲染
const userName = useUserStore(state => state.user.name, shallow);

步骤2：处理跨store通信

使用zustand的subscribeWithSelector中间件监听状态变化：

// 当filters变化时自动刷新tickets
useEffect(() => {
  const unsub = useFilterStore.subscribe(
    state => state.filters,       // selector
    (filters) => {
      useTicketStore.getState().fetchTickets(filters);
    },
    { equalityFn: shallow }       // 深度比较
  );
  return unsub;
}, []);

步骤3：适配Vue 3的响应式系统

Pinia天然支持Vue 3的ref和reactive，但需要注意避免解构丢失响应性：

import { storeToRefs } from 'pinia';
const ticketStore = useTicketStore();

// 正确：使用storeToRefs保持响应性
const { tickets, loading } = storeToRefs(ticketStore);

// 错误：直接解构会丢失响应性
// const { tickets, loading } = ticketStore;

5. 踩坑与优化：那些文档没写的事

坑1：Zustand的set函数浅合并陷阱

Zustand的set默认是浅合并，如果state中有嵌套对象，需要手动处理不可变更新：

// 错误：直接修改嵌套对象
set(state => {
  state.user.profile.name = 'newName'; // 不会触发更新
  return state;
});

// 正确：创建新对象
set(state => ({
  user: {
    ...state.user,
    profile: { ...state.user.profile, name: 'newName' }
  }
}));

// 或使用immer中间件
import { immer } from 'zustand/middleware';
const useStore = create(immer((set) => ({
  updateName: (name) => set(state => {
    state.user.profile.name = name; // 直接修改，immer自动处理不可变
  })
})));

坑2：React 18的并发模式与zustand的冲突

当使用React 18的startTransition时，zustand的同步更新可能导致状态丢失。解决方案：使用useSyncExternalStore的selector模式：

import { useSyncExternalStore } from 'react';

function useTicketSelector(selector) {
  return useSyncExternalStore(
    useTicketStore.subscribe,
    () => selector(useTicketStore.getState()),
    () => selector(useTicketStore.getState()) // 服务端渲染时使用
  );
}

优化：使用React.memo + zustand的useStore避免不必要的渲染

// 优化后的组件定义
const TicketItem = React.memo(({ ticketId }) => {
  // 只订阅单个ticket，不订阅整个数组
  const ticket = useTicketStore(state => 
    state.tickets.find(t => t.id === ticketId)
  );

  return {ticket.title};
});

6. 效果数据：重构前后的性能对比

使用Chrome Performance录制5分钟操作，关键指标如下：

指标 重构前 重构后 提升
组件重渲染次数(5min) 1,284 357 72.2%
平均渲染时间(ms) 12.3 4.1 66.7%
页面切换耗时(ms) 680 210 69.1%
首屏加载时间(ms) 2,100 1,300 38.1%
内存占用(MB) 85 53 37.6%

Vue 3 + Pinia的模块同样显著：Vue Devtools中组件更新次数从每秒45次降到12次，computed重新计算减少80%。

7. 总结：什么时候该用状态管理库？

  • 用Context/Props就够的场景：组件树深度≤3层，状态变更频率低（如主题色、语言），且只有少量组件消费
  • 必须上状态管理库的场景：组件树深度≥5层，多组件共享频繁变更的状态（如上万条列表的筛选条件），需要跨模块通信（如用户登录状态影响所有模块）

建议迁移路径：先分析性能火焰图，找到重渲染的根组件，然后用zustand的slice模式逐步剥离，每次只迁移一个模块，验证性能后再继续。不要为了用而用——如果项目只有3个组件，用Context更简单。

最后，Zustand的devtools中间件在调试时非常有用，配合React DevTools可以精确追踪每次状态变更的来源。这也是我放弃Redux的原因之一：状态管理库应该是解决问题的工具，而不是制造问题的源头。