React中嵌套useContext Provider的使用逻辑及多上下文疑问

在学习useContext时，我对嵌套Provider的使用场景感到困惑。以下是React文档中的示例代码：

// Theme context, default to light theme
const ThemeContext = React.createContext('light');

// Signed-in user context
const UserContext = React.createContext({
  name: 'Guest',
});

class App extends React.Component {
  render() {
    const {signedInUser, theme} = this.props;

    // App component that provides initial context values
    return (
      <ThemeContext.Provider value={theme}>
        <UserContext.Provider value={signedInUser}>
          <Layout />
        </UserContext.Provider>
      </ThemeContext.Provider>
    );
  }
}

function Layout() {
  return (
    <div>
      <Sidebar />
      <Content />
    </div>
  );
}

// A component may consume multiple contexts
function Content() {
  return (
    <ThemeContext.Consumer>
      {theme => (
        <UserContext.Consumer>
          {user => (
            <ProfilePage user={user} theme={theme} />
          )}
        </UserContext.Consumer>
      )}
    </ThemeContext.Consumer>
  );
}

文档中对该示例的解释为：

为保持上下文重渲染的高效性，React需要将每个上下文消费者作为树中的独立节点。如果两个或多个上下文值经常一起使用，可以考虑创建自己的渲染属性组件来同时提供它们。

我的疑问：

1. 创建多个createContext和Provider仅出于性能考量吗？是否存在其他使用场景？
2. 既然useContext可全局使用，为何还需要多个上下文？

解答 #

1. 多上下文的使用场景不止性能优化

性能是重要考量，但还有更多核心场景：

• 职责分离与可维护性：不同上下文对应不同的业务维度（比如主题、用户信息、权限、语言），每个上下文只负责单一类型的数据。后期修改时，不用在臃肿的全局上下文中查找零散数据，也不会因为修改某类数据影响到不相关组件，代码逻辑更清晰。
• 局部作用域需求：并非所有状态都需要全局共享。比如某个表单模块的状态、弹窗专属上下文，只需要在局部组件树中生效，拆分多上下文可以避免全局上下文过度膨胀，实现局部状态的隔离管理。
• 模块化与复用性：独立的上下文可以封装成单独模块（比如ThemeContext），能在其他项目或组件库中直接复用，不用依赖无关的上下文模块，提升代码复用性和模块化程度。
• 降低组件耦合：如果把所有状态塞进一个上下文，组件会被迫消费不需要的数据，导致组件与无关状态耦合；拆分后组件只消费自己需要的上下文，耦合度大幅降低。

2. useContext“全局可用”不代表要只用一个上下文

useContext的“全局”指的是可以在组件树任意位置消费已提供的上下文，但这和“只用一个上下文”是两回事：

• 单一全局上下文会导致“牵一发而动全身”：只要上下文里任意一个值变化，所有消费它的组件都会重渲染，哪怕组件只用到其中一个值，造成大量不必要的性能损耗。
• 单一上下文违反单一职责原则：把用户、主题、权限等所有状态混在一起，上下文职责模糊，代码维护难度指数级上升。
• 多上下文能实现精准更新：每个上下文只管理一类状态，只有消费对应上下文的组件才会在状态变化时重渲染，既保证性能，也让状态管理更清晰。

内容的提问来源于stack exchange，提问作者Sol_is_here