4、状态管理优化：全局状态与局部状态的划分，Context/Redux/Zustand的性能陷阱，状态更新的批量处理与防抖节流

状态管理，说白了就是低代码平台的「血液系统」。血液流得顺畅，平台就快；流得堵了，整个页面就卡死。我见过太多团队，一上来就把所有数据塞进全局状态，结果页面渲染次数比用户点击次数还多。

这一章，咱们就聊聊怎么给状态「减肥」，怎么避开那些常见的性能陷阱。

4.1 全局状态 vs 局部状态：别什么都往「大仓库」里塞

很多新手有个误区：把所有数据都放到 Redux 或 Zustand 里，觉得这样「统一管理」最省事。其实不然。

全局状态，适合那些真正需要跨组件共享的数据。比如用户登录信息、主题配置、多语言包。这些数据一旦变了，很多地方都得跟着变。

局部状态，就是组件自己管自己的数据。比如一个表单的输入值、一个弹窗的开关状态、一个列表的加载状态。这些数据，别人不关心，也没必要关心。

我个人习惯，先问自己三个问题：

• 这个数据，有没有两个以上不相关的组件需要它？
• 这个数据变了，会不会引起页面大范围重渲染？
• 这个数据，能不能用 useRef 或 useState 搞定？

如果答案都是「否」，那就别往全局状态里塞。

我在项目中遇到过这样一个案例：一个低代码表单设计器，每个字段的「是否必填」「默认值」等属性，都被放到了 Redux 里。结果用户每修改一个字段，整个属性面板都要重新渲染。后来我把这些属性改成了组件的局部状态，渲染次数直接降了 70%。

4.2 Context/Redux/Zustand 的性能陷阱

这三个工具，各有各的坑。咱们一个一个说。

4.2.1 Context：小心「连锁反应」

React 的 Context，有个很隐蔽的问题：只要 Context 的值变了，所有消费这个 Context 的组件都会重新渲染，不管它们用到的数据有没有变。

举个例子：

// 一个包含用户信息和主题的 Context
const AppContext = createContext();

function AppProvider({ children }) {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');

  return (
    <AppContext.Provider value={{ user, theme, setUser, setTheme }}>
      {children}
    </AppContext.Provider>
  );
}

// 某个组件只用了 theme
function ThemeButton() {
  const { theme } = useContext(AppContext);
  return <button className={theme}>点击</button>;
}

问题在哪？当 user 变了，ThemeButton 也会重新渲染。它明明只关心 theme 啊！

4.2.2 Redux：订阅粒度太粗

Redux 的 useSelector 默认是浅比较。如果你返回一个新对象，哪怕里面的值没变，也会触发重渲染。

// 错误写法：每次返回新对象
const data = useSelector(state => ({
  name: state.user.name,
  age: state.user.age
}));

// 正确写法：分开订阅
const name = useSelector(state => state.user.name);
const age = useSelector(state => state.user.age);

嗯，这里要注意。我见过一个项目，整个页面就一个 useSelector，把整个 store 都拉进来了。结果随便改个字段，整个页面白屏半天。

4.2.3 Zustand：隐式的全局订阅

Zustand 比 Redux 轻量，但也不是没有坑。它的 useStore 默认是全局订阅的。如果你不小心，也会引起不必要的渲染。

// 错误写法：订阅了整个 store
const store = useStore();

// 正确写法：只订阅需要的字段
const count = useStore(state => state.count);

说白了，Zustand 的「自由」是有代价的。你得自己控制订阅粒度。

4.3 状态更新的批量处理与防抖节流

低代码平台里，用户操作往往很频繁。拖拽组件、调整属性、输入文本……每一次操作都可能触发状态更新。如果不做处理，性能会急剧下降。

4.3.1 批量更新：把多次更新合并成一次

React 18 默认支持自动批处理。但在某些场景下，比如异步回调或原生事件中，还是需要手动处理。

// React 18 自动批处理
function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // 只会触发一次渲染
}

// 异步回调中，React 18 也支持批处理
fetch('/api/data').then(() => {
  setData(result);
  setLoading(false);
  // 只会触发一次渲染
});

如果你还在用 React 17 或更早版本，可以用 unstable_batchedUpdates 手动合并。

4.3.2 防抖：延迟执行，避免频繁触发

防抖适合「输入搜索」「窗口调整」这类场景。用户连续操作时，只执行最后一次。

import { debounce } from 'lodash';

// 防抖处理搜索输入
const handleSearch = debounce((value) => {
  setSearchTerm(value);
  // 触发 API 请求
}, 300);

// 在输入框 onChange 中调用
<input onChange={(e) => handleSearch(e.target.value)} />

我在项目中遇到过：一个低代码平台的属性面板，用户每输入一个字符，就触发一次状态更新和渲染。加了防抖后，输入流畅多了。

4.3.3 节流：控制执行频率

节流适合「拖拽」「滚动」这类场景。保证一段时间内只执行一次。

import { throttle } from 'lodash';

// 节流处理拖拽事件
const handleDrag = throttle((position) => {
  setPosition(position);
}, 100);

// 在拖拽事件中调用
<div onDrag={(e) => handleDrag({ x: e.clientX, y: e.clientY })}>
  拖拽我
</div>

4.4 实战建议：低代码平台的状态管理策略

说了这么多，咱们总结一下在低代码平台里，怎么落地这些优化策略。

场景	推荐方案	注意事项
用户登录信息	全局状态（Context 或 Zustand）	用 useMemo 包裹 value，避免不必要的更新
组件属性编辑	局部状态（useState）	每个组件独立管理自己的属性
拖拽位置	局部状态 + 节流	用 throttle 控制更新频率
搜索输入	局部状态 + 防抖	用 debounce 延迟触发 API 请求
多组件共享数据	Zustand 或 Redux Toolkit	订阅粒度要细，避免全量订阅

你想想看，低代码平台的核心是什么？是让用户快速搭建页面。如果状态管理没做好，页面卡顿，用户早就跑了。

我个人习惯，在项目初期就定好状态管理的「边界」。哪些数据进全局，哪些数据留局部，写进团队规范里。这样后期维护起来，省心不少。