React 19与Vue 3.5下的状态管理迁移：从Props钻取到Zustand/Pinia的工程化实践

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

先说一下项目现状。我负责的是一个B端数据可视化平台，React 19 + TypeScript 5.6，组件树深度平均8层。旧架构里，全局状态（用户权限、主题配置、筛选条件）通过Context.Provider层层下发，子组件通过useContext获取。问题在三个月后集中爆发：

1. 渲染失控：Context值一旦变化，所有消费该Context的组件无论是否依赖具体数据，都会强制重渲染。我们用React.memo做了优化，但嵌套层级深的组件依然频繁更新。实测一次简单的主题切换，触发86次组件render，其中42次是无意义的。
2. 调试困难：Context的value是一个巨型对象，DevTools里查看变化时根本分不清哪个字段变了。加日志又污染代码。
3. 逻辑复用性差：多个页面需要共享同一份筛选状态，只能将状态提升到顶层，然后通过props一层层传递。新增一个中间组件，所有props接口都得改。

另一个Vue 3.5项目问题类似，但表现形式不同：Props深链传递导致每次数据变更，中间组件的update周期频繁触发，且由于Vue的响应式追踪，调试时很难定位是哪个组件率先修改了数据。

二、环境与版本：为什么选Zustand和Pinia

在选型阶段，我们对比了以下方案：

最终选择Zustand和Pinia的核心原因：它们都不要求将状态集中到一个全局store，可以按业务模块拆分多个store，且支持在组件外部读取状态（适合路由守卫、工具函数）。这一点对现有代码的侵入性最小。

三、方案设计：渐进式替换而非重写

我们没有采取“大爆炸式”迁移，而是设计了三步渐进策略：

1. 识别核心状态：将全局状态分为三类：
2. 跨页面共享（用户token、权限码、主题）
3. 页面内共享（列表筛选条件、分页参数）
4. 临时UI状态（弹窗开关、加载动画）

只迁移前两类，第三类继续用组件本地state。这样迁移风险可控。

1. 接口兼容层：在创建Zustand store时，保持与旧Context相同的API形状（即value对象的key不变）。这样迁移过程中，组件内部只需要把useContext(MyContext)替换为useStore()，逻辑代码几乎不动。

2. 分批替换：按“先叶子组件、后中间组件”的顺序替换。先改最深层的消费组件，确认没问题后，再向上移除Context Provider。

四、核心实现：从Context到Zustand的落地

4.1 旧Context代码（React 19）

// 旧：Context + useReducer
const AppStateContext = createContext(null);

function AppProvider({ children }: { children: React.ReactNode }) {
  const [state, dispatch] = useReducer(appReducer, initialState);
  const value = useMemo(() => ({ state, dispatch }), [state]);

  return (

      {children}

  );
}

// 消费组件（第8层）
const { state, dispatch } = useContext(AppStateContext);
if (!state) return null; // 还得判空

这段代码的问题：value每次state变化都会变，所有useContext(AppStateContext)的组件都会重渲染。即使组件只关心state.theme，也会因state.user变化而重新render。

4.2 新Zustand store（v5）

// 新：Zustand store
import { create } from 'zustand';

interface AppStore {
  theme: 'light' | 'dark';
  user: UserInfo | null;
  permissions: string[];
  setTheme: (theme: 'light' | 'dark') => void;
  setUser: (user: UserInfo) => void;
  updatePermission: (perm: string) => void;
}

export const useAppStore = create((set) => ({
  theme: 'light',
  user: null,
  permissions: [],
  setTheme: (theme) => set({ theme }),
  setUser: (user) => set({ user }),
  updatePermission: (perm) => 
    set((state) => ({ permissions: [...state.permissions, perm] })),
}));

// 消费组件（第8层）
const theme = useAppStore((state) => state.theme);
const setTheme = useAppStore((state) => state.setTheme);

关键改动点：
- 使用useAppStore((state) => state.theme)精确订阅，只有theme变化时组件才会重渲染。
- 无需在顶层包裹Provider，store是单例。
- 支持在组件外部调用（例如API拦截器里更新token）。

4.3 Vue 3.5项目：从Props到Pinia

旧代码（Vue 3.5 + Composition API）：

const filter = ref({ search: '', page: 1 });
function handleFilterChange(newFilter) {
  filter.value = newFilter;
}

新代码（Pinia v3）：

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

export const useFilterStore = defineStore('filter', {
  state: () => ({
    search: '',
    page: 1,
    pageSize: 20,
  }),
  actions: {
    setSearch(search: string) {
      this.search = search;
    },
    setPage(page: number) {
      this.page = page;
    },
  },
  getters: {
    totalParams: (state) => ({
      search: state.search,
      page: state.page,
    }),
  },
});

// 任意子组件
const filterStore = useFilterStore();
const page = computed(() => filterStore.page);

Pinia的好处是天然支持storeToRefs，解构后保持响应性，且DevTools插件可以时间旅行调试。

五、踩坑与优化：3个典型问题

5.1 Zustand的selector返回新对象导致死循环

问题：直接在selector里返回新对象：

const userInfo = useAppStore((state) => ({
  name: state.user?.name,
  avatar: state.user?.avatar,
}));

这会导致无限重渲染，因为Zustand使用Object.is比较，每次selector都返回新引用。

解决：使用useShallow：

import { useShallow } from 'zustand/react/shallow';

const userInfo = useAppStore(
  useShallow((state) => ({
    name: state.user?.name,
    avatar: state.user?.avatar,
  }))
);

5.2 Pinia的store在组件外使用需注意

问题：在路由守卫中使用store，如果store尚未被任何组件实例化，会警告“getActivePinia was called but there was no active Pinia”。

解决：在main.ts中提前创建并传递pinia实例：

// main.ts
const pinia = createPinia();
app.use(pinia);
// 路由守卫中
export function authGuard(to, from, next) {
  const userStore = useUserStore(pinia); // 显式传入pinia实例
  // ...
}

5.3 迁移过程中的过渡状态

问题：部分组件还在用Context，部分已切换到Zustand，导致状态不一致。

解决：写了一个临时的同步中间件——在Provider中订阅Zustand store的变化，同步到Context。但注意这个过渡方案只运行了两周，全部迁移完成后立即删除。

六、效果数据：性能变化与团队反馈

迁移完成后，我们做了对比测试（同一台MacBook Pro M2，Chrome 130，React应用使用Vite 6，Vue应用使用Vite 5）：

团队反馈：新成员上手时间从3天缩短到1天，因为只需要看store定义就能理解全局状态流。同时，由于Zustand/Pinia都内置了DevTools插件，联调效率提升明显——以前排查状态问题需要打日志，现在直接看时间线。

七、总结与建议

如果你也面临Context/Props钻取的困境，我的建议是：

1. 不要为了迁移而迁移。如果组件树深度小于5层，且状态更新频率低，Context完全够用。只有当出现“页面卡顿”、“调试困难”、“逻辑复用难”这三个信号时，才考虑引入状态管理库。
2. 优先选极简方案。Zustand和Pinia的学习成本几乎为零，且API设计更符合直觉。Redux和Vuex适合大型团队，但中小型项目用它们反而拖慢速度。
3. 渐进式迁移。一次性重写风险极高，按模块拆分，每完成一个模块就测试一个模块。我们用了两周时间平稳过渡，期间没有出现线上事故。

最后提一句，React 19的use() Hook和Vue 3.5的reactive虽然可以缓解部分问题，但它们解决的是“数据获取”问题，而非“状态共享”问题。状态管理库在可维护性上的优势，短期内无法被原生API替代。

如果你们也在迁移过程中遇到了其他坑，欢迎在评论区交流。