前端状态共享方案对比与实战经验分享

优化前：卡得不行

上周上线一个带复杂筛选+实时预览的配置页，用户一打开就卡住。不是“有点卡”，是那种鼠标移过去都掉帧、点个按钮要等半秒才有反应的程度。我本地开发时没感觉，因为数据量小，但一上测试环境，加载 200+ 条配置项，每个组件都订阅了全局状态，直接崩了。

最离谱的是，明明只是改了个筛选条件，整个页面所有组件都在重新渲染。Chrome DevTools 的 Performance 面板里，一次简单操作能触发 50+ 次 React 组件更新，主线程直接拉满。同事开玩笑说：“这页面不是在跑，是在挖矿。”

找到瓶颈了！

我先用 React DevTools 的 Highlight Updates 功能看了下，好家伙，一改筛选条件，整个页面红成一片。说明几乎所有组件都被迫 rerender 了。问题出在状态共享机制上——我们用的是最原始的 Context + useReducer，把所有状态塞进一个 context 里，任何微小变动都会让所有 useContext 的组件重新渲染。

接着用 Performance 录制了一次完整操作：

• 初始加载：5.2s（白屏 3s+）
• 切换筛选：主线程阻塞 1.8s
• 内存占用：稳定在 120MB+

确认是状态更新粒度太粗导致的无效渲染。核心问题不是状态本身大，而是“读写不分”——哪怕只改一个字段，所有依赖任意字段的组件都得重算。

试了几种方案，最后这个效果最好

第一反应是拆 Context。把大状态拆成多个小 Context，比如 FilterContext、PreviewContext。但拆完发现组件还是互相影响，因为有些组件同时依赖多个上下文，只要其中一个变了，照样全刷。而且维护成本高，容易漏拆。

然后想到用 Zustand。它基于 Proxy，天然支持细粒度订阅。但项目里已经重度依赖 React Context，迁移成本太高，临时换状态库风险大。

折腾半天，决定用 memoization + selector 改造现有 Context。核心思路：让组件只订阅自己需要的状态片段，而不是整个 state。关键代码就两步：

1. 改造 Provider，加入 selector 机制

// 原始写法（问题根源）
const AppContext = createContext();
export const useAppContext = () => useContext(AppContext);

// 优化后：支持 selector
export const useAppContext = (selector) => {
  const context = useContext(AppContext);
  if (!context) throw new Error('useAppContext must be used within AppProvider');
  
  // 如果没传 selector，返回整个 state（兼容旧代码）
  if (!selector) return context.state;
  
  // 用 useMemo 缓存 selector 结果
  return useMemo(() => selector(context.state), [context.state, selector]);
};

2. 组件里只取需要的字段

// 优化前：订阅整个 state
const { filters, previewData, loading } = useAppContext();

// 优化后：只订阅 filters
const filters = useAppContext(state => state.filters);
// 另一个组件只订阅 previewData
const previewData = useAppContext(state => state.previewData);

这里注意我踩过好几次坑：
– selector 必须是稳定引用（比如用 useCallback 包裹），否则 useMemo 会失效
– 不要直接在组件里 inline 写 selector，比如 useAppContext(state => state.x)，每次渲染都会创建新函数，导致缓存失效。正确做法：

// ✅ 正确：用 useCallback 稳定 selector
const selectFilters = useCallback(state => state.filters, []);
const filters = useAppContext(selectFilters);

// ❌ 错误：每次渲染都新建函数
const filters = useAppContext(state => state.filters);

另外，对于深层嵌套对象，记得用结构化克隆或 immutable 库避免引用污染。我们项目里用了 Immer，所以 state 更新本身就是不可变的，这点省了不少事。

性能数据对比

改完后跑了一遍相同测试：

• 初始加载：从 5.2s 降到 820ms（首屏内容提前 2.5s 出现）
• 切换筛选：主线程阻塞从 1.8s 降到 90ms
• 组件 rerender 次数：从 50+ 次降到 3-5 次（只有真正依赖 filters 的组件更新）
• 内存占用：稳定在 65MB 左右（减少近 50%）

最直观的感受是：页面操作跟手了，滚动流畅，筛选响应几乎无延迟。连产品经理都跑来问：“你偷偷加了什么黑科技？”

还有个小问题，但无大碍

当然，这方案不是银弹。如果 selector 逻辑特别复杂（比如要遍历大数组做计算），可能反而拖慢性能。我们后来加了个简单规则：selector 里只做属性提取，复杂计算放到组件内或用 useMemo 单独处理。

另外，老组件迁移需要时间。我们没一次性全改，而是新功能强制用 selector，旧组件逐步替换。现在还有 2-3 个非关键组件没改，但不影响整体体验。

核心代码就这几行

完整改造其实就改了两个文件。贴出来供参考：

// AppContext.js
import { createContext, useContext, useMemo } from 'react';

const AppContext = createContext(null);

export const AppProvider = ({ children, initialState, reducer }) => {
  const [state, dispatch] = useReducer(reducer, initialState);
  const contextValue = useMemo(() => ({ state, dispatch }), [state, dispatch]);
  
  return (
    <AppContext.Provider value={contextValue}>
      {children}
    </AppContext.Provider>
  );
};

// 支持 selector 的 hook
export const useAppContext = (selector) => {
  const context = useContext(AppContext);
  if (!context) throw new Error('useAppContext must be used within AppProvider');
  
  if (!selector) return context.state;
  
  return useMemo(() => selector(context.state), [context.state, selector]);
};

// Component.js
import { useAppContext } from './AppContext';

// 稳定 selector
const selectFilters = (state) => state.filters;
const selectIsLoading = (state) => state.loading;

const FilterPanel = () => {
  // 只订阅需要的部分
  const filters = useAppContext(selectFilters);
  const loading = useAppContext(selectIsLoading);
  
  // ...其他逻辑
};

以上是我的优化经验，有更好的方案欢迎交流

这次优化让我深刻体会到：状态共享不是“能不能用”，而是“怎么用得聪明”。Context 本身没问题，问题在于我们滥用它。加上 selector 机制后，既保留了 Context 的简单性，又获得了细粒度更新的能力，成本低效果好。

如果你也在用单一 Context 管理复杂状态，不妨试试这个方案。代码改动小，收益大。当然，如果有更优雅的解法，比如结合 React 18 的 useSyncExternalStore，也欢迎评论区聊聊。毕竟前端优化这事儿，永远没有终点，只有更顺滑的体验。