本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一时间和你分享前端行业趋势，学习途径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi ，包含一线大厂面试完整考点、资料以及我的系列文章。
更新（重新渲染）是 React 的重要特性 —— 当用户与应用交互的时候，React 需要重新渲染、更新 UI，以响应用户的输入。但是，React 为什么会重新渲染呢？如果不知道 React 为什么会重新渲染，我们如何才能避免额外的重新渲染呢？
TL; DR
状态改变是 React 树内部发生更新的唯二原因之一。
这句话是 React 更新的公理，不存在任何例外。本文也将会围绕解释这句话展开。为了避免有人抬杠，这句话引入了一些限制定语和关键词：
名词解释
「更新」和「重新渲染」
在 React 中，「更新」和「重新渲染」是关系紧密，但是含义完全不同的两个词。下面这句话才能正确表达这两个词的正确含义：
React 的「更新」包含三个阶段：渲染（Render），使用 createElement 或 jsx-runtime 产生全新的 React Element 对象、组装出一颗 React 树；Reconcilation，React Reconciler 比较 新生成的 React 树 和 当前的 React 树，判断如何用最高效的方法实现「更新」；Commit，操作 Host（如 DOM、Native 等），使新的 UI 呈现在用户面前。
大部分开发者会把「更新」和「重新渲染」混为一谈，因为在上述三个阶段中，只有「渲染」这一阶段是开发者可以控制的（「Reconcilation」和「Commit」分别由 react-reconciler 和 React Host 控制）。本文接下来的部分中，「重新渲染」一律指代 React 组件在「更新」时的「渲染」阶段，而「更新」则一律指代（重新）渲染、Reconcilation 和 Commit 整个过程。
「React 树」和「React 树内部」
React Tree 本身可以在任意时候更新。实际上，如果你曾经通过 React 文档学习 React，你在「Hello World」一章就已经见过这个 Pattern 了：
const root = ReactDOM.createRoot(document.getElementById('root'));
function tick() {
const element = (
Hello, world!
It is {new Date().toLocaleTimeString()}.
);
root.render(element);
// 如果你是在 React 18 发布以前学习的 React，你可能会用 ReactDOM.render()：
// ReactDOM.render(element, document.getElementById('root'));
}
setInterval(tick, 1000);每秒钟调用一次 ReactDOM 提供的 render 使一整颗 React 树进行了完整的更新。但是绝大部分时候，你不会更新一整颗 React 树，而是 React 树内的一部分组件（在 React 应用中，你只会调用一次 createRoot().render 或者 hydrateRoot()）。
「唯二原因」
如果你在使用 React class 组件，那么你可以使用继承自 React.Component 的 forceUpdate 方法更新一个组件：
class MyComponent extends React.Component {
handleInput() {
this.forceUpdate();
}
}因此，我们也可以把这句话改写成：如果一颗 React 树中所有的 class 组件都没有使用 forceUpdate 方法，那么状态改变是这颗 React Tree 内部发生更新的唯一原因。
在正文开始之前，先放出一句非常具有迷惑性的话：
误区 0：React 组件更新有三个原因：状态改变，prop 改变，Context 改变。
如果你去问一些使用 React 的开发者「为什么 React 会更新/重新渲染」，大概会得到这个答案。这句话不无道理，但是并不能反应真实的 React 更新机制。
本文只会介绍 React 为什么会发生更新，不会介绍如何避免「不必要」的更新（也许我会以这个为话题另外写一篇文章？）。
状态更新和单向数据流
让我们以计数器为例：
const BigNumber = ({ number }) => (
{number}
);
const Counter = () => {
const [count, setCount] = useState(0);
const handleButtonClick = useCallback(() => setCount(count => count + 1), []);
return (
在这个例子中，我们声明了三个组件，根组件 count，当点击按钮时会改变状态 count、使其递增。
当我们点击按钮的时候，setCount 被调用、count 状态发生改变，React 更新了
现在让我们先厘清一个最简单的误区：
误区 1：当一个状态发生改变时，整颗 React 树都会更新。
有少数使用 React 的开发者会相信这一点（还好不是大多数！）。实际上，当状态发生改变的时候，React 只会更新「拥有这个状态」的组件，和这个组件的所有子组件。
为什么父组件（在这个例子中，count 向下流向了 number，但是不可能向上流向了 组件。因此，count 状态改变，
当 count 状态改变时，number 的新的值进行渲染。那么 number 的改变吗？
不，和 props 完全没有关系
误区 2：React 组件更新的其中一个原因是它的 prop 发生了改变。
现在让我们修改一下上面那个例子：
import BigNumber from './big-number';
const SomeDecoration = () => Hooray!
const Counter = () => {
const [count, setCount] = useState(0);
const handleButtonClick = useCallback(() => setCount(count => count + 1), []);
return (
prop、不使用其父组件 的 count 状态，但是当 count 状态发生改变时，prop：React 并不能百分之百肯定 count 状态。
理想中，每一个 React 组件都应该是一个 纯函数 —— 一个「纯」的 React 组件，当输入相同的 props 时，总是会渲染相同的 UI。但是现实是骨感的，我们非常容易写出一个「不纯」的 React 组件：
const CurrentTime = () => Last rendered at {new Date().toString()}
包含了状态（使用了 useState）的组件也不是纯组件：即使 prop 不改变，组件也会因为状态不同而渲染出不同的 UI。
有的时候，你很难判断一个组件是否是纯组件。你可能会将一个 Ref 作为 prop 传递给一个组件（forwardRef，useImperativeHandle，诸如此类的 case）。Ref 本身是 Reference Stable 的、React 并不能知道 Ref 中的值是否改变。
React 的目标是展示最新、维持一致的 UI。为了避免向用户展示过时的 UI，当父组件更新时，React 会更新所有子组件，即使子组件不接受任何 prop。props 和组件更新没有任何关系。
纯组件和 memo
你大概很熟悉（或者至少听说过）React.memo、shouldComponentUpdate 或者 React.PureComponent，这些工具允许我们「忽略更新」：
const SomeDecoration = memo(() => Hooray!);当我们将 组件的声明包裹在 memo 中时，我们实际上做的是告诉 React「嘿！我觉得这是个纯组件，只要它的 prop 不改变，我们就别更新它」。
现在，让我们把 memo 中，看看会发生什么：
const BigNumber = memo(({ number }) => (
{number}
));
const SomeDecoration = memo(() => Hooray!);
const Counter = () => {
const [count, setCount] = useState(0);
const handleButtonClick = useCallback(() => setCount(count => count + 1), []);
return (
现在，当 count 状态更新后，React 会更新 number，而 number 的值发生了改变，因此 prop 没有发生改变（因为不接受任何 prop），所以 React 跳过了
于是你想，为什么 React 不默认所有组件都是纯组件呢？为什么 React 不 memo 所有组件呢？事实上，React 组件更新的开销没有想象中的那么大。以 组件为例，它只需要渲染一个 。
如果一个组件接受很多复杂的 prop，有可能渲染这个组件并对比 Virtual DOM 的性能开销甚至小于等于浅比较所有 prop 的开销。绝大部分时候，React 是足够快的。因此，只有当一个 纯组件 有大量纯的子组件、或者这个 纯组件 内部有很多复杂计算时，我们才需要将其包裹在 memo 中。
当一个包裹在 memo 中的组件使用了useState、useReducer或者useContext，当这个组件内的状态发生改变时，这个组件仍然会更新。
另外一个 React 默认不 memo 所有组件的原因是：让 React 在 Runtime 中判断子组件的全部依赖、以跳过子组件的不必要更新，是非常困难、非常不现实的。计算子组件依赖的最好时机是编译期间。关于这个 idea 的更多细节，可以看看黄玄在 React Conf 2021 上的演讲 React without memo。
让我们谈谈 Context
误区 3：React 组件更新的其中一个原因是 Context.Provider 的 value 发生了更新。
如果说，当一个组件由于状态改变而更新时，其所有子组件都要随之更新。那么当我们通过 Context 传递的状态发生改变时，订阅了这个 Context 的所有子组件都要更新也是毫不意外的了。
对于纯组件来说，Context 可以视为一个「隐藏的」、或者「内部的」prop：
const User = memo(() => {
const user = useContext(UserContext);
if (!user) {
return 'Hello, new comer!';
}
return `Hello, ${user.name}!`;
})在上面的例子中，prop、不使用 useState、也没有任何副作用的纯组件。但是，UserContext。当 UserContext 保存的状态发生改变时，
众所周知，当 Context 的 value 发生改变的时候，所有 value 发生改变的根本原因还是状态的改变：
const CountContext = createContext(0);
const BigNumber = memo(() => {
const number = useContext(CounterContext);
return (
{number}
)
});
const Counter = () => {
const [count, setCount] = useState(0);
const handleButtonClick = useCallback(() => setCount(count => count + 1), []);
return (
正如上面的例子，CountContext 发生改变的原因，是 CountContext 的消费组件（及其子组件），还包括
代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。
来源：https://blog.skk.moe/post/react-re-renders-101/
交流
有梦想，有干货，微信搜索 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试完整考点、资料以及我的系列文章。
