提取React Context提供者逻辑至自定义Provider为何能避免不必要重渲染？

咱们先拆解第一种写法的问题根源：

• 你把UserContext.Provider直接放在了App组件里，而且user是App的本地state，change函数也是在App内部定义的。每次点击Change按钮触发setUser时，App的state更新，整个App组件都会重新渲染。
• 这时候，App每次渲染都会重新创建一个全新的{user, change}对象作为Provider的value——哪怕user的值只是更新了，但这个对象的引用是完全新的。
• 更关键的是，App重渲染时，它返回的整个JSX树都会被重新生成，A作为App的直接子组件会被触发重渲染，接着B作为A的子组件也会跟着渲染，最后才到C。哪怕A和B完全没用到Context，也会被牵连进来做无意义的渲染。

再看第二种写法为啥能解决问题：

• 你把Provider的状态管理逻辑抽到了独立的UserProvider组件里，这时候user和change都变成了UserProvider内部的东西，和App组件彻底解绑了。
• 当点击Change按钮触发state更新时，只有UserProvider会重新渲染，而App组件因为没有自身状态变化，完全不会重渲染。
• UserProvider的children是从props传进来的<A/>，因为App没重渲染，这个<A/>的引用是稳定不变的——React会识别到这一点，不会重新创建A和B的组件实例，自然也就不会触发它们的重渲染。
• 最后，只有订阅了UserContext的C组件，会检测到Context值的变化（新的user对象），从而触发必要的重渲染，完全不会影响到A和B。

简单总结一下：自定义Provider把状态管理和上层组件（App）解耦了，既避免了上层组件重渲染牵连子树，又保证只有真正依赖Context的组件才会响应变化。

备注：内容来源于stack exchange，提问作者barciewicz