React 从零到一执行原理 (2025 最新版)

最新推荐文章于 2025-05-12 18:10:57 发布

TE-茶叶蛋

最新推荐文章于 2025-05-12 18:10:57 发布

阅读量1k

点赞数 10

分类专栏：面试复习系列 react 文章标签： react.js 前端前端框架

本文链接：https://blog.csdn.net/Bruce__taotao/article/details/147867976

版权

面试复习系列同时被 2 个专栏收录

17 篇文章

订阅专栏

react

5 篇文章

订阅专栏

文章目录

前言

前言

整理一份React最新版本从零到一的执行原理分析，涵盖源码层面的机制解析，以及开发者视角下的组件构建、生命周期、渲染流程等内容。整理将包括：React如何解析JSX、构建Fiber树、协调与调度过程、生命周期钩子的执行时机、事件系统、context（类似Vue的provide/inject），到最终的DOM渲染或hydration过程。

1. 编译与运行机制：JSX 转译与虚拟 DOM 生成

React 采用 JSX 语法来描述 UI，这是一种 JavaScript 的语法扩展，类似 HTML。浏览器无法直接识别 JSX，因此在构建阶段需要将 JSX 转译为普通 JavaScript。通常由 Babel 编译器完成这一步：Babel 会将 JSX 代码解析为 AST，并将每个 JSX 元素转换为对 React.createElement() 函数的调用。例如，<MyComponent prop="value" /> 会被编译为 React.createElement(MyComponent, { prop: "value" }, null) 的形式。

React.createElement 返回一个 React 元素对象，可以视为虚拟 DOM 节点的表示。每个元素对象包含组件类型（例如标签名或组件类）、属性 (props)、子元素等信息。这些 React 元素组成了应用的 虚拟 DOM 树，它是保存在内存中的对 UI 的理想化表示。在初次渲染时，React 利用这些元素对象构建出内部的组件树和 DOM 树，然后调用 ReactDOM.render（React 18+中使用createRoot(...).render）将虚拟DOM渲染为真实 DOM，插入页面。从此之后，React 会在每次状态更新时重新执行组件的渲染函数，生成新的虚拟DOM树，并将其与先前的虚拟DOM进行比较。

2. Fiber 架构与调和 (Reconciliation) & 调度 (Scheduling)

React 16 引入了全新的 Fiber 架构，这是对核心算法的重写。Fiber 可以理解为一种数据结构和调度机制，它将渲染工作拆分为更细粒度的单元，以支持 增量渲染 和 可中断渲染。每个组件对应一个 Fiber 对象，可看作轻量的“虚拟栈帧”。Fiber 节点中保存了该组件的类型（函数组件、类组件或原生节点等）、对应的元素类型和关键属性、以及与真实 DOM 节点或组件实例的引用（即 stateNode）。例如，对于类组件，stateNode 指向组件实例；对于函数组件则没有实例（通常为 null），对于 DOM 元素则指向具体的 DOM 元素节点。此外，每个 Fiber 还包含指向父 Fiber、第一子 Fiber、下一个兄弟 Fiber 以及上一次渲染的 备用 Fiber (alternate) 等指针，用于构成一棵链表树结构。通过这种结构，React 能在内部维护两棵 Fiber 树：一棵当前屏幕上显示的 current 树，和一棵正在重新计算中的 work-in-progress 树，用于本次更新。

调和算法 (Reconciliation)：当状态或属性更新时，React 会根据新的数据重新渲染受影响的组件，产生新的虚拟DOM（即新的 Fiber 树）。React 随后将新的 Fiber 树与当前 Fiber 树进行对比，找出最小差异，这个过程称为调和(diffing)。为了使 diff 高效可预测，React 基于两条重要的启发式假设：(1) 不同类型的元素会产生不同的树结构，因此如果节点类型变更（例如从 <div> 变为 <span> 或从一个组件类变为另一个），React 不尝试复用，直接卸载旧节点挂载新节点；(2) 开发者可以通过 key 属性提示哪些子元素在不同渲染中可视为相同，从而在列表 diff 时实现高效复用和重排。遵循这两个原则，React 能以近 O(n) 的复杂度完成虚拟DOM树的差异比较，而不是理想算法的 O(n^3) 复杂度。在调和过程中，如果发现节点更新，则标记相应的 Fiber 有 Update 等副作用标志；对于新创建的节点则标记 Placement 插入标志，需新增真实DOM；被删除的节点标记 Deletion 等等。所有有副作用的 Fiber 会被收集到一个效果列表中，准备进入提交阶段。

Fiber 调度 (Scheduling)：Fiber 架构最大的改进在于可中断、可恢复的调度机制。旧版（React 15及以前）的渲染递归执行、一气呵成，可能导致主线程长时间被占用。而 Fiber 将渲染拆解为一个个单元任务（Fiber 单元），并使用一个循环来逐个处理这些单元——调用开始工作 (beginWork) 函数计算 Fiber 子树，再调用完成工作 (completeWork) 函数收尾。在 渲染阶段（Render Phase），React 会执行这个工作循环(workLoop)遍历 Fiber 树，每处理完一个 Fiber 节点就看看是否需要让出控制权，从而在长任务时将控制权交还给浏览器，以响应更高优先级的用户交互。这样的 合作式调度 使得渲染工作可以分段进行，在空闲时间继续未完成的工作。React 内部通过优先级或任务车道 (lane) 系统来标记不同更新的紧急程度，并配合浏览器的调度器（如 scheduler 包或 MessageChannel）来安排任务顺序。总的来说，Fiber 的异步可中断特性意味着 React 可以在新更新到来时暂停当前渲染、处理更高优先级的更新，然后再恢复之前的渲染，或丢弃已不需要的渲染结果。这保证了在大量更新时浏览器依然能够响应用户输入，不会长时间卡顿。

当新的 Fiber 树构造完毕并完成调和后，React 进入 提交阶段（Commit Phase）。此时所有需要应用的更改已经确定在 Fiber 树的副作用列表中，React 会一次性地将这些更改提交到真实 DOM 中。提交阶段是同步且不可中断的，但由于之前调和阶段已将更改范围降到最小，所以提交通常很快。提交包括三类操作：

DOM 更新：对于标记了更新的 Fiber，执行对应的 DOM 属性更新、文本节点内容更新等。对于需要新增或删除的节点，在此阶段进行实际的插入或移除操作。
调用生命周期：在DOM变更完成后，调用类组件的生命周期回调（如 componentDidMount/componentDidUpdate 等）和触发 useLayoutEffect、useEffect 等 Hook 的执行（区别详见后文生命周期章节）。
切换 Fiber 树：最后，React 将新的 Fiber 树设为 current 树，并将旧的 Fiber 树作为备用树。这样下次更新时，新旧 Fiber 树将对调角色，实现双缓冲机制，提高渲染效率。

通过上述过程，React 确保只对真实 DOM 执行必要的最小操作。例如首次渲染时，React 会使用 appendChild 将创建的所有 DOM节点挂载到容器中；而在更新渲染时，React 只会对比前后虚拟DOM树的差异，仅应用必要的DOM操作使真实UI与最新虚拟DOM同步。这种批量差异更新的方式极大提高了性能。总而言之，Fiber 架构将 React 的渲染流程划分为渲染(diff)阶段和提交(commit)阶段两部分：渲染阶段可以被打断、具有优先级调度，提交阶段则一次性应用变更。借助 Fiber，React 实现了更灵活高效的调和算法和更新调度机制，为后续并发渲染等高级特性打下基础。

3. 组件构建过程：函数组件 vs 类组件，Hooks 执行机制

在 React 中，组件主要有两种定义方式：函数组件和类组件。它们在内部执行和 Fiber 树构建上有所区别：

类组件 (Class Component)：React 会通过 new 调用组件类的构造函数来创建组件实例（保存于 Fiber 的 stateNode 中）。随后依次调用生命周期方法：如果定义了 getDerivedStateFromProps（静态方法）则在构造或更新前调用以派生状态，然后调用组件的 render() 方法生成 React 元素树。当 Fiber 调和完成并进入提交阶段挂载后，React 调用该实例的 componentDidMount() 完成首次挂载流程。类组件的实例在整个组件生命周期中保持存在，因此组件的本地状态 (this.state) 存储在实例上，通过调用 this.setState() 触发更新。每次更新时会生成一个新的 Fiber，并复用原来的组件实例来比较 prevProps/prevState 执行更新流程，从而保持状态连续性。
函数组件 (Function Component)：函数组件本质上就是一个接收 props 并返回 JSX 的函数。React 调用函数组件时不会创建组件实例，Fiber 的 stateNode 对于函数组件为 null。函数组件没有 this，因此不能直接拥有本地状态或使用生命周期方法。取而代之的是，React 提供了 Hooks API 来让函数组件“获得”类似状态和副作用管理的能力。React 在调用函数组件时，会按照代码顺序执行其中的 Hook 调用（如 useState、useEffect 等），通过内部的机制将状态和副作用与当前的 Fiber 关联起来。

Hooks 的执行机制：Hooks 依赖于 React Fiber 对函数组件状态的管理。可以将每个 Hook 调用想象为组件 fiber 上的一块内存单元（或称“Hook 链表节点”），其中保存该 Hook 调用相关的状态或回调等数据。React 为每个函数组件 Fiber 维护一个 hooks 链表（通过 Fiber 的 memoizedState 指向链表头）。在组件初次渲染时，React 按顺序初始化每个 Hook：

对于 useState，React 会创建一个带有 { memoizedState: 初始值, queue: 更新队列, next: 下一个 hook } 等属性的 Hook 对象，保存在链表中。它返回的 state 值来自 memoizedState，更新函数则会将新的更新对象加入该 Hook 的更新队列，触发 Fiber 更新。
对于 useEffect/useLayoutEffect，React 记录下效果函数和依赖数组等，并在提交阶段安排执行（useLayoutEffect 同步于DOM更新后执行，useEffect 延迟到浏览器空闲时执行）。这些 effect 的清理函数会在组件卸载或下一次 effect 执行前被调用。
其他 Hooks（如 useContext、useMemo 等）亦类似，通过内部的 dispatcher 分发在初次和更新时不同的处理逻辑。

在后续更新时，React 再次调用函数组件时会重用之前创建的 hooks 链表。它靠调用顺序来匹配 Hook：React 内部维护一个当前 Hook 的指针，每调用一次 Hook 函数（如调用了第一个 useState），就顺着链表移动到下一个节点，从中读取之前保存的状态值并根据需要更新。因此 Hooks 必须在组件顶层以固定顺序调用——这一“Hooks 规则”正是为了保证每次渲染时 Hook 序列的一一对应。如果调用顺序或数量不一致（例如在循环或条件中调用 Hook），就会破坏这种对应关系，从而导致错误。

简而言之，函数组件通过 Hooks 机制实现与类组件类似的功能：useState 提供可变状态，useEffect 等提供副作用管理，相当于类组件的生命周期方法。内部实现上，类组件的状态存储在组件实例上，而函数组件的状态则存储在 Fiber 的 Hooks 链表中；类组件的更新通过调用实例的生命周期，函数组件的更新通过再次执行函数组件并利用之前的 Hook 状态完成。注意：由于函数组件每次渲染都会重新执行函数体，因此不能像类组件那样使用实例字段来存储跨渲染的值，而需要借助 useRef 等 Hook 来保持引用。总体而言，函数组件配合 Hooks 提供了更灵活的组合模式和更细粒度的状态管理，与 Fiber 架构契合良好，因此在现代 React 开发中已成为主流。

4. 生命周期执行流程：类组件生命周期 vs 函数组件 Hooks

React 类组件有完整的生命周期方法，在挂载、更新和卸载阶段分别调用。React 16以后建议使用的新生命周期方法及其调用顺序如下：

挂载阶段 (Mounting)：
1. constructor(props)：组件实例构造函数。用于初始化状态 (this.state = ...) 及绑定事件方法等。
2. static getDerivedStateFromProps(props, state)：在 render() 调用前触发的静态方法，根据传入的 props 派生状态。一般不常用，只有在需要根据 props 改变内部 state 时使用。
3. render()：返回组件的 JSX 结构（React 元素树）。这是一个纯函数，应根据当前 props 和 state 计算 UI，不执行副作用。
4. componentDidMount()：组件已经挂载到真实 DOM 后调用。适合在此执行副作用，如发起网络请求、订阅事件等。
更新阶段 (Updating)：(当组件的 props 或 state 改变时触发)
1. static getDerivedStateFromProps(props, state)：每次更新时也会在 render 前调用，以根据新props调整状态。
2. shouldComponentUpdate(nextProps, nextState)：在重新渲染前触发，返回值决定是否继续更新流程。可用于控制组件避免不必要的重新渲染（默认为返回 true）。
3. render()：和挂载时一样，根据新状态和属性重新计算 JSX。必须是纯计算且不可有副作用。
4. getSnapshotBeforeUpdate(prevProps, prevState)：在最近一次渲染的输出即将提交到 DOM 前调用。它允许组件在 DOM 更新前捕获一些信息（例如滚动位置）。该方法返回值将作为第三参数传递给 componentDidUpdate。
5. componentDidUpdate(prevProps, prevState, snapshot)：组件更新后且真实 DOM 已同步完成时调用。此时可以操作 DOM（比如根据 snapshot 滚动恢复）、发起后续请求等副作用。此外需注意避免在此方法中直接调用 setState 导致死循环，如需根据更新结果更新状态，应加条件判断。
卸载阶段 (Unmounting)：
1. componentWillUnmount()：组件即将从 DOM 中移除时调用。可在此执行清理工作，比如清除计时器、取消网络请求、移除事件监听等。

以上是常用的生命周期方法调用顺序。另外在错误处理方面，如果在子组件渲染过程中抛出未捕获错误，会触发错误边界组件的 static getDerivedStateFromError(error) 和 componentDidCatch(error, info) 方法，可用于捕获错误并更新状态显示降级UI。

函数组件没有上述显式生命周期方法，但可以通过 Hooks 达到同样效果：

挂载：使用 useEffect(..., []) 来模拟，只在组件初次挂载后运行一次其回调（依赖数组为空数组）。这相当于 componentDidMount。如果需要在组件卸载时清理，可在 useEffect 的回调中返回一个清理函数，相当于 componentWillUnmount。
更新：使用 useEffect 并指定依赖数组 [dep1, dep2]，React 会在指定的依赖发生变化且组件重新渲染后，调用该 effect。这类似于 componentDidUpdate（但需要自行控制依赖范围）。另外，每次 effect 执行前，上一次的清理函数会被调用，可以看作更新前的清理，相当于 getSnapshotBeforeUpdate 的用途场景（例如记录上一次 DOM 状态）。
卸载：如上，useEffect 的清理函数会在组件卸载时执行，等价于 componentWillUnmount。

还有一些特殊的 Hooks 对应特定的生命周期场景：

useLayoutEffect：它与 useEffect 类似，但执行时机在所有 DOM 变更后、浏览器绘制之前（在同一个提交阶段完成）。因其执行更早，可以获取DOM最新布局并同步调整，适合需要阻塞浏览器绘制以执行测量或布局调整的场景（类似于类组件中的 componentDidMount/DidUpdate但执行时机略早，更像getSnapshotBeforeUpdate + componentDidUpdate结合）。
useMemo / useCallback：虽然不直接对应生命周期，但用于在渲染之间缓存计算结果或函数引用，避免每次 render 都重新计算或生成新的函数。这可以类比于 shouldComponentUpdate 中跳过某些变化或 PureComponent 的浅比较优化——通过确保属性引用稳定来减少不必要子组件更新。
useRef：允许在函数组件中存储跨渲染周期保持不变的可变值，可用于替代实例字段，例如保存之前的状态值或者DOM元素引用等。
useImperativeHandle：配合 forwardRef 使用，可让父组件通过 ref 获取子组件暴露的实例方法，类似类组件方法暴露。
useTransition 和 useDeferredValue：React 18 引入的新Hook，用于标记和处理非紧急更新及延迟值，在并发模式下优化更新体验（后文将提及）。

小结：类组件生命周期使开发者能够在组件不同阶段介入逻辑，而函数组件则通过 Hooks 将这些逻辑分散到各个 hook 中，但本质上两者在 Fiber 更新流程中都会被正确地调度。需要注意的是，在React严格模式 (Strict Mode) 下，为了帮助发现副作用的隐患，React 会在开发环境中对初次渲染的组件执行额外一次重复的调用（仅影响非HOOK的部分，如函数组件会执行两次函数体，类组件的 constructor 和 render、useEffect的清理和执行也会各执行两次）。这一行为不影响生产环境，但要求副作用代码具备幂等性或做好防范。

5. 上下文 (Context) 机制与事件系统

Context 上下文机制

React 的 Context 提供了一种在组件树间共享数据的方法，避免逐层通过props传递。使用时，首先通过 React.createContext(defaultValue) 创建一个 Context 对象，然后在上层组件使用 <Context.Provider value={/*一些值*/}> 包裹下层组件，将数据提供给树中深层的后代组件。任意深度的后代组件都可以通过 useContext(MyContext) Hook（或 <MyContext.Consumer>）直接读取最近祖先提供的 context 值，而无需通过中间组件手动传递。例如，应用的主题、当前认证用户等可用 Context 来管理，这些数据对很多组件都是“全局”的。

Context 的实现原理可以简单概括为：每个 Provider 组件将其 value 放入 React 内部的 Context 结构中，React 在渲染过程中会让下层的 Consumer/useContext 订阅这个 Context。当 Provider 的 value 发生改变时，所有订阅了该 Context 的组件都会触发重新渲染，以获取新值。因此Context是响应式的：只要 Provider 用新值重新渲染，Consumer 组件也会更新UI。这和 Vue3 中提供的 provide/inject 响应性有些类似，但需要注意 Vue2 的 provide/inject 默认不是响应式的。

**对比 Vue 的 provide/inject：**在 Vue 2 中，provide/inject 用于祖先向后代注入依赖，但注入的数据在后代组件中并非响应式更新的（除非注入的是Vue的响应式对象）。Vue 3 对 provide/inject 进行了改进，允许注入 ref 等响应式数据，从而后代会随数据变化而更新。React 的 Context 则天然支持响应：Context 的值变化会使 Consumer 重新渲染。但频繁变动的大型数据不建议放入 Context，因为这可能导致过多的组件更新，影响性能。

归纳一下，两者用途类似，都是为了解决跨层级的属性传递问题。不同的是，React Context 通常通过在组件树上以 Provider->Consumer 形式使用，API 风格偏组件化；而 Vue 提供选项式或组合式 API (provide()/inject()) 来声明。Vue2 的 inject 不响应、Vue3 支持响应式，而 React Context 则总是使Consumer响应更新。在使用上，需要谨慎控制 Context 值的变化频率；如果遇到性能问题，可考虑将 Context 分割、使用 memo 或优化避免不必要子组件订阅。

事件系统与子父通信

React 有自己的一套合成事件 (SyntheticEvent)系统。它对浏览器的原生事件进行了封装和代理，提供跨浏览器的一致行为。在 JSX 中，我们直接使用如 onClick={handleClick} 的方式给元素绑定事件处理函数，但这些事件并没有真正绑定到DOM节点上。React 实际采取了事件委托的策略：在应用的根节点（或更高层，如 React 17+是在应用挂载的根容器上）注册一个事件监听器，当事件发生并冒泡至根时，React 拦截事件并根据发生事件的目标元素，找到对应的React组件及其注册的处理函数，然后以合成事件对象为参数调用处理函数。例如，我们在多个按钮元素上都添加了onClick，但最终在DOM中可能只有一个共享的点击事件监听器，它挂在应用根节点上。当任意按钮被点击时，事件冒泡到根，由React统一处理，然后调用对应按钮组件的事件handler。这种机制减少了需要注册的DOM事件监听数量，提升性能，同时合成事件对不同浏览器的事件行为进行了标准化（如事件对象属性、取消默认行为方式等），开发者使用时无需考虑浏览器兼容问题。

阻止事件冒泡和默认行为：由于React采用事件委托，调用e.stopPropagation()和e.preventDefault()依然有效，且React为了符合浏览器习惯，在合成事件中实现了这些方法，并确保在合成事件中调用它们会应用到原生事件上。此外需要注意，React的合成事件并非真实 DOM 事件，所以不能直接用 addEventListener 去监听由 React 合成事件触发的东西，要在React体系内使用onEvent属性。

事件触发与组件通信：在 Vue 中，子组件可以通过调用 this.$emit('eventName', data) 来向父组件发送事件，父组件用 <Child @eventName="handler" /> 接收，实现子->父通信。React 没有内建类似 $emit 的机制，但可以通过回调函数 prop实现同样的目的：即父组件将一个函数通过props传递给子组件，子组件在需要时调用该函数，并可传入需要传递的数据参数。例如父组件 <Child onSave={handleSave} />，子组件内触发保存时调用 props.onSave(data)，这样父组件的 handleSave 就被执行，拿到子组件传来的数据。这种方式其实与 Vue 的 $emit 本质相同，只是 React 更加明确地通过数据流（props）来配置，不采用全局事件总线。对于非直接父子的通信，常用的方法包括提升状态至共同祖先组件、利用 Context 或使用像 Redux 这样的全局状态管理库等。

综上，React 的事件系统通过合成事件和委托提高了性能和兼容性。组件间通信则遵循单向数据流理念，主要通过 props 回调 实现父子通信，这相比 Vue 的 $emit 更为直接但需要多写一些样板代码。React 不鼓励使用全局事件总线来传递状态，更推荐通过组件组合、上下文或状态管理来实现跨层级通信，这保证了数据流向的清晰和可维护性。

6. DOM 渲染：首次挂载与更新过程

React 将虚拟DOM转变为真实DOM的过程分为首次挂载和更新渲染两种情况：

首次挂载 (Initial Mount)：当调用 ReactDOM.createRoot(container).render(<App/>)（旧版为 ReactDOM.render）时，React 会根据根组件 <App> 生成完整的虚拟DOM树和对应的 Fiber 树。Fiber 的调和阶段会为每个元素创建真实 DOM 节点，例如 <div> 会创建一个 DOM <div>元素，文本节点会创建文本节点。这些 DOM 节点暂存在内存中，尚未插入页面。当 Fiber 树构建完毕，进入提交阶段时，React 会使用诸如 container.appendChild(domNode) 等原生 DOM 操作，将整个组件树的 DOM 节点依次附加到容器上。至此，初始界面渲染完毕。期间React会调用组件的 componentDidMount 等生命周期通知完成。初次挂载因为没有旧DOM需要比较，基本就是创建并插入全部节点。
更新渲染 (Re-render)：当组件调用 setState 或接收新的 props 导致状态变化时，React 会触发一次更新渲染。它首先根据新的 state/props 重新执行组件的 render 方法（或函数组件函数），生成新的虚拟DOM和 Fiber 树，然后将这棵新树与上一次渲染保留的旧 Fiber 树进行调和(diff)比较（如前文所述的 Fiber 调和过程）。对于未改变的部分，React 会复用之前的 DOM 节点，不做任何操作；对于有变化的部分，React 标记需要更新的 Fiber 节点。在随后的提交阶段，React 根据 diff 结果对真实DOM执行最小化的更新操作：
- 对需要更新内容的 DOM节点，调用如 element.setAttribute 或直接修改 textContent 等来更新属性和文本。
- 对需要新增的节点，创建对应DOM并插入到父DOM的正确位置。React 跟踪每个 Fiber 的位置以及兄弟顺序，如果有新增 Fiber 标记了 Placement，会使用如 parent.insertBefore(newDom, referenceDom) 将新节点插入指定位置。
- 对需要删除的节点，从其父DOM中移除对应的 DOM 元素（同时React会调用组件的卸载生命周期等进行清理）。

在这个更新过程中，React 只改动必要的部分，如果某次更新并未改变某些子树，则那些子DOM完全不会动，从而保证高效。描述了这一点：重新渲染时，React 计算出了需要改动的属性，而不会在计算阶段就更新DOM，直到进入提交阶段才批量应用变更。同时，如果前后渲染结果没有区别，React 连提交阶段都省略。这就是虚拟DOM diff算法带来的性能优化：通过在内存中比较两棵虚拟DOM树，避免了不必要的真实DOM操作。

DOM 更新示例：假设组件渲染输出由 <ul> 列表变为长度更长的列表。调和时，React 会比较每个 <li> 的 key，找出新增了哪些 <li>。对于新增的项，对应 Fiber 会标记 Placement，在提交阶段React创建这些 <li> DOM并插入。而对于未变的项，只更新内容或保持原状，对应 DOM 不移动。这样的按需更新避免了全量重绘，提高了效率。

需要注意的是，React 在更新DOM时对浏览器进行了批处理和调度优化。例如，在一个事件处理函数中如果连续调用了多次 setState，React 不会同步逐次更新DOM，而是批量合并这些更新后再统一执行一次渲染和DOM更新。这种 批量更新 (batching) 机制在React 18中扩展到了所有环境（包括异步回调等）——以往只有在React控制的事件中才自动批量处理，18后即使在例如setTimeout中调用多个setState也会自动批量处理，避免中间不必要的重复渲染。

总结来说，React的DOM渲染分为初次渲染整个挂载和后续的差量更新。初次渲染创建并插入所有元素，而更新渲染则通过Fiber调和算法找出变化之处，只更新必要的DOM。这种按需更新结合批处理和优先级调度，既保证了界面状态的正确同步，又最大化地减少了直接操作DOM的次数，从而提供良好的性能。

7. React 18+ 新特性：并发更新 (Concurrent Features)、服务端组件等

随着 React 18 的发布，React 引入了一系列新特性和改进，进一步提升应用的性能和开发体验。其中具有代表性的是并发渲染特性和服务端组件，以及相关的新API：

并发渲染 (Concurrent Rendering)：React 18 将此前实验性的“并发模式”正式引入。并发渲染并非一项单一功能，而是React底层调度模型的升级。启用并发后（通过使用 createRoot 而非旧的 render 接口，应用即进入并发渲染模式），React 的更新不再总是同步阻塞的——渲染过程可以被打断、暂停，并随后恢复或丢弃。这意味着React可以同时准备多个版本的UI更新，在空闲时优先渲染更紧急的更新，从而提高应用响应速度。例如，当一个低优先级更新正在处理中，如果用户触发了高优先级的交互（如输入文本），React可以中途暂停低优先级更新，先处理用户输入对应的更新，再回来继续之前的工作。并发渲染通过 Fiber 的优先级和调度机制实现，React 使用内部的优先队列、多缓冲技术来保障最终UI的一致性——React 会等待整个新树计算完毕再一次性提交DOM变更，从而避免中间状态不一致。并发特性本身对开发者来说是透明的，但解锁了多种新功能：
- 自动批处理 (Automatic Batching)：在React 18之前，只有在React管理的事件处理中，多次 setState 会自动合并批量更新；但在异步回调（如定时器、原生事件）中每次 setState 都会触发单独更新。React 18 实现了“自动批处理”，将所有微任务/宏任务中的更新都自动合并，在下一个事件循环统一渲染。这减少了不必要的重复渲染，提高性能且无需开发者手动调用 unstable_batchedUpdates 等。
- 过渡 (Transitions)：提供了新的 startTransition API 和 useTransition Hook，允许开发者将一些状态更新标记为“非紧急”过渡更新。被标记为过渡的更新在并发模式下会被赋予较低优先级，从而不会阻塞紧急更新。例如在切换页面内容时，可以使用 startTransition 将页面内容状态的更新标记为过渡，这样如果用户在过渡过程中还有输入等操作，React 会优先响应用户输入（高优先级），而将过渡渲染推迟一点完成，从而避免掉帧。这种机制提高了应用在交互过程中的流畅度。
- Suspense 加强：React 18 将之前的 Suspense 用于数据加载的能力在并发模式下完善了。Suspense 可以让组件在等待异步数据时显示后备UI（如加载指示器），并在数据准备好后无缝切换。这在并发渲染下变得更高效：React 可以并发地渲染未来可能显示的UI，而不阻塞当前界面，让加载指示器及时显示，并在后台准备完真实内容后再呈现。同时React 18支持服务端流式渲染与 Suspense 结合，使服务端渲染的应用也可以逐步流式输出HTML，提高首屏速度。
- useDeferredValue：这是另一个与并发相关的新Hook，作用是延迟某些值的更新。它可以将一个及时变动的值（如输入框内容）派生出一个“延迟版本”，从而让大量依赖该值的计算不会在每次微小变动时都触发，而是略滞后于真实值。这对实现输入防抖、避免高频率重新渲染很有帮助。

并发渲染使上述功能成为可能，而且这些改进在绝大多数情况下对现有应用是向后兼容的。需要注意的是，由于并发渲染引入了更新过程中的不确定顺序（渲染可能被打断），某些以前同步执行的副作用代码需要遵循新的约束（比如避免假定状态立即更新）。React 团队也提供了Strict Mode下的双调用机制来帮助发现并解决潜在问题。

React 服务端组件 (Server Components)：服务端组件是React在18之后推出的重大变革之一。以往，React的服务器渲染（SSR）是在服务器上将组件渲染为HTML字符串，再发送到客户端hydrate。但服务端组件 (RSC) 的概念更进一步：允许我们编写的某些组件只在服务器环境执行，其产生的UI片段直接发送给客户端，而无需发送这些组件的JavaScript代码。根据React官方定义，服务端组件是在与常规客户端应用隔离的环境中 预先渲染（可以在构建时或每次请求时）的一类组件。它们运行在Node.js等服务器端，可以直接访问后端资源（如数据库、文件系统），然后将生成的结果（序列化的React元素或特殊标记）发送给客户端，与客户端组件共同组成最终UI。

服务端组件的核心优势在于零客户端开销：因为它的代码不打包进客户端JS里。例如，一个重型的Markdown解析组件可以做成服务端组件，解析 Markdown 为HTML在服务器完成，这样客户端无需加载解析库JS，也无需占用浏览器资源进行计算，只需接受解析后的结果。服务端组件通过一种特殊协议将其输出传递给前端，同步到React应用中。它与Suspense集成：客户端在遇到服务端组件边界时可以先呈现Loading，等服务器返回结果后再显示内容。值得一提的是，服务端组件不是对SSR的替代，而是与SSR协同工作：我们可以有一部分UI由SSR直接输出（初始页面），而后续交互产生的新UI片段通过RSC机制请求。Next.js 13 就基于React 18+的Server Components提供了应用目录 (app/)的全新数据获取和渲染模式，将组件分为服务端组件和客户端组件两类 ("use client" 指令标记客户端组件)以充分利用这一特性。

React 19 宣布服务端组件相关API已稳定，但构建工具层面的集成可能在19.x小版本中仍会有调整。目前使用服务端组件通常需要框架支持（如Next.js的编译器和Babel插件）。尽管如此，服务端组件为React应用带来了新的性能优化思路：在保证良好用户体验的前提下，将更多工作卸载到服务器端完成，减少客户端的JavaScript负担。
其他新特性：
- 新Hooks：如前面提到的 useId（用于生成稳定的唯一ID，解决SSR/CSR不一致的ID问题）、useSyncExternalStore（为状态管理库提供一致的外部状态读取接口）、useInsertionEffect（在DOM变更前插入CSS的hook，用于CSS-in-JS优化）等。
- 批处理改进：除自动批处理外，React 18还默认开启了争取一次渲染多状态更新的策略，例如在事件处理函数之外的异步回调中，多个连续的状态更新也会自动合并。
- 并发UI挂起优化：如引入了 <SuspenseList> 组件可以协调多个Suspense的顺序，以及即将推出的 <Offscreen> 隐藏/恢复UI组件（在并发模式下可以卸载不显示的UI以节省性能并保留其状态）。

综上，React 在 18 及以后的版本通过 Fiber并发更新 模型带来了更顺畅的用户体验：渲染变得可中断、可调度，应用在繁忙时段依然响应迅速；通过新API开发者可以将一些更新标记为过渡，从而在繁重更新过程中保持界面互动的流畅。同时，服务端组件等特性的出现，进一步发挥了同构应用的威力，减轻客户端负担、提升首屏速度。作为开发者，我们可以逐步引入这些特性来优化应用，但也需了解其工作原理（如并发渲染下生命周期的变化）以避免踩坑。React 18/19 是一个新的开始，很多特性（如并发渲染、RSC）为未来的React应用奠定了基础，充分理解这些原理有助于更好地利用React构建高性能的现代Web应用。

参考文献：