使用 React Context 修复嵌套组件树中的不必要重新渲染

Source: Dev.to

并非所有 React 性能问题都会以错误形式出现。
有些会在开发时悄然出现，当一次简单的 UI 交互感觉比实际更沉重时。

本文将通过一个真实的开发时问题来说明，这个问题是由属性钻取（prop drilling）和不恰当的状态放置导致的——以及如何通过重构状态来消除不必要的重新渲染、API 调用和繁重的 UI 更新。

该应用使用 React 并渲染了一个基于 Highcharts 的可视化组件（重新渲染代价高）。在组件树的深层（2–3 层下）有一个带按钮的子组件。

需求

点击按钮时显示一个模态框。纸面上看很简单。

初始实现

模态框的状态在父组件中定义。

const Parent = () => {
  const [isModalOpen, setIsModalOpen] = useState(false);

  useEffect(() => {
    fetchData();
  }, []);

  return ;
};

setIsModalOpen 通过属性层层传递，直到传到按钮。

 setIsModalOpen(true)}>
  Open modal

功能上可以工作，但在架构上存在问题。

测试时的观察

在开发中随意测试该功能时，我注意到：

• 按钮点击后出现明显的 UI 暂停
• Highcharts 重新渲染
• API 调用再次被触发

每一次点击都会导致父组件状态更新，这意味着：

• 父组件重新渲染
• 与父组件关联的副作用再次执行
• 昂贵的 UI 被不必要地重新初始化

功能没有坏掉——但代价是真实存在的。

根本原因

状态放置不当。

• 模态框状态仅用于 UI。
• 它位于负责数据获取和繁重渲染的父组件中。
• 属性钻取把局部交互紧耦合到了全局副作用。

这是一种在 React 应用规模扩大时常见的架构泄漏。

解决方案：使用 Context 隔离 UI 状态

彻底把模态框状态从父组件中移除，改为使用专门的 Context 来管理模态框可见性。

import { createContext, useState } from "react";

const ModalContext = createContext(null);

export const ModalProvider = ({ children }) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <ModalContext.Provider value={{ isOpen, setIsOpen }}>
      {children}
    </ModalContext.Provider>
  );
};

在最合适的顶层边界放置 Provider。需要打开或关闭模态框的组件直接消费该 Context：

import { useContext } from "react";

const { setIsOpen } = useContext(ModalContext);

不再需要属性钻取，也不再需要父组件参与。

结果

进行上述改动后：

• 父组件在打开模态框时不再重新渲染。
• API 调用仅在明确需要时才执行。
• Highcharts 保持稳定。
• UI 交互感觉即时且可预测。

对用户而言行为保持不变，但架构更清晰、性能更好。

关键要点

• 属性钻取会隐藏性能问题，即使代码本身是正确的。
• 仅用于 UI 的状态不应与数据获取逻辑混在一起。
• 如果按钮点击会触发不相关的副作用，说明状态边界设置错误。
• Context API 不仅用于全局数据——它同样适用于隔离 UI 关注点。

React 中的性能问题往往是伪装的设计问题。