> ## Documentation Index
> Fetch the complete documentation index at: https://opc-43d279b8.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# React 版本演进史
> 从 FaxJS 到 React 19，梳理版本演进、Fiber 架构、事件系统与生命周期变迁。
> React 的版本演进可以按"每次重写解决了什么"来记：栈调和卡在哪、Fiber 补上了什么、Hooks 又换掉了哪种写法。
***
## Q1: React 的历史？为什么要有它？
```text theme={null}
┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ 2010 XHP+PHP │ → │ 2011 FaxJS │ → │ 2012 Instagram │ → │ 2013 开源发布 │ → │ 2015 React 15 │
│ UI 危机 │ │ 函数式原型 │ │ 内部验证 │ │ 虚拟 DOM 亮相 │ │ Stack Reconciler│
└────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘
```
**1. 2010 年 - Facebook 的 UI 危机**
Facebook 当时用 PHP + XHP（PHP 的 XML 扩展）拼接 HTML DOM。通知系统是重灾区——用户收到一条新消息，需要手动查询 DOM 节点、判断是否已存在、再插入或更新。随着消息类型（点赞、评论、@提及）不断膨胀，代码变成一团意大利面条，状态与 DOM 严重耦合，修一个 bug 冒出三个新 bug。
**2. 2011 年 - Jordan Walke 的原型 FaxJS**
Facebook 工程师 Jordan Walke 受 XHP（Facebook 内部的 PHP XML 扩展框架）的启发——XHP 让开发者在 PHP 中用 XML-like 语法构建 UI 组件。Walke 将这个思想带入 JavaScript，构建了 FaxJS 原型。核心思想：**UI = f(state)**——给定一个状态，函数返回一棵描述 UI 结构的轻量对象树（即虚拟 DOM 的雏形）。状态变化时重新调用函数生成新树，框架自动 diff 两棵树的差异并更新真实 DOM。开发者从此不再手动操作 DOM。Walke 在 2019 年的演讲中回顾了这段经历，称 React 的设计灵感来自"函数式编程对 UI 的重新定义"\[1]。
**3. 2012 年 - Instagram 的验证**
Facebook 内部孵化出 Instagram 后，团队面临"从零构建一个完整 SPA"的需求。他们选择用 FaxJS 的思想来驱动 Instagram 的前端。这次内部验证证明了声明式 UI 的可行性——代码量大幅减少，bug 率显著降低，团队开始认真打磨这套方案。
**4. 2013 年 - React 开源（JSConf US）**
2013 年 5 月，JSConf US 上 Pete Hunt 做了"Rethinking Web App Development at Facebook"演讲，React 正式开源\[2]（Jordan Walke 是 React 的主要作者）。虚拟 DOM + JSX 的组合震惊了业界——"在 JavaScript 里写 HTML？"引发了巨大争议。Pete Hunt 在演讲中强调："React 不是在教你怎么做 UI，而是在教你如何思考 UI——把 UI 看成数据的函数输出。"Facebook 花了很长时间说服社区接受"关注点分离不是文件分离，而是组件分离"的理念。早期生态极不完善，没有路由、没有状态管理，但核心思想逐渐被验证。
**5. 2015 年 - React 15（Stack Reconciler）**
React 15 采用 Stack Reconciler 架构：用同步递归遍历虚拟 DOM 树做 diff。这个架构简单直接，在中小型应用中表现良好。但它的致命问题是**同步且不可中断**——一旦开始 diff，就必须一口气跑完整棵组件树，大型应用可能阻塞主线程 100ms+，导致掉帧和输入延迟。
> [!TIP]
>
> React 诞生之前的操作 DOM 就像用纸质账本管理仓库——每来一批货（新数据），你得手动翻账本（查询 DOM）、核对数量、涂改记录（修改 DOM），账本越厚越容易出错。React 就像引入了一套 ERP 系统——你只需要录入数据（声明状态），系统自动生成最新的库存报表（渲染 UI），再也不用手工对账了。
**React 诞生解决的核心问题：**
```text theme={null}
问题：手动操作 DOM + 状态与视图耦合 = 代码混乱、难以维护
新消息到达 → 手动查询 DOM → 判断节点是否存在 → 插入或更新 → 状态散落在各处
解决：声明式 UI — 状态驱动视图，框架自动 diff 更新
state 变化 → 调用 render() → 生成新虚拟 DOM → diff 对比 → 只更新变化的真实 DOM
```
> [!NOTE]
>
> React 的诞生源于 Facebook 的 UI 维护危机，Jordan Walke 用"UI = f(state)"的函数式思想创造了虚拟 DOM，让开发者从手动操作 DOM 的泥潭中解放出来。
> [card] 没有 React（2010 年之前）
>
> 前端用 jQuery 手动操作 DOM，状态散落在各种全局变量和 DOM 属性中。通知系统每来一条消息就要 `document.querySelector` + `if/else` 判断 + `appendChild`，就像一个仓库管理员没有任何清单系统，每次取货都要满仓库翻找。
> [card] 引入 React（2013 年之后）
>
> 声明式 UI 让开发者只需描述"UI 应该长什么样"，框架负责 diff 和更新。就像仓库引入了智能库存系统——管理员只需要说"我要 5 号货架上的东西"，系统自动定位、取货、更新库存记录。
> [!TIP]
>
> 回答时先说"为什么"（Facebook 的 UI 维护危机），再说"怎么解决"（声明式 UI + 虚拟 DOM）。想听的是你对技术诞生驱动力的理解，而不是背诵年份。
***
## Q2: React 15 的问题是什么？怎么解决？
### Stack Reconciler 的致命问题
React 15 的协调器（Stack Reconciler）采用同步递归算法遍历整棵组件树。当 `setState` 触发更新时，React 从根节点开始递归对比每个组件的虚拟 DOM，这个过程一旦开始就无法中断。
```text theme={null}
setState 触发
│
▼
┌──────────────────────────────────────────┐
│ 同步递归遍历整个组件树 │
│ 每个组件: shouldComponentUpdate? │
│ → render() 生成新虚拟 DOM │
│ → diff 对比新旧虚拟 DOM │
│ → 收集差异 │
│ │
│ 无法中断！必须一口气跑完！ │
│ 大型应用: 100ms+ 阻塞主线程 │
└──────────────────────────────────────────┘
│
▼
commit 更新到真实 DOM
```
核心问题有三个：
1. **同步递归无法中断**：JavaScript 的调用栈是后进先出结构，递归过程中无法在中间状态暂停并恢复。大型应用一次更新可能占用主线程 100ms+，直接导致掉帧。
2. **没有优先级概念**：所有更新一视同仁——用户输入和数据加载的更新享有相同优先级，无法优先响应用户交互。
3. **大型组件树性能悬崖**：组件数量越多，递归深度越深，性能呈线性下降，且没有优雅的降级方案。
### React 15 的优化尝试
面对这些问题，React 15 时期社区和官方提供了三种优化手段：
**1. shouldComponentUpdate（手动中断递归）**
```javascript theme={null}
class ListItem extends React.Component {
shouldComponentUpdate(nextProps) {
// 如果数据没变，跳过该子树的 diff
return nextProps.item.id !== this.props.item.id;
}
render() {
return {this.props.item.name}
;
}
}
```
`shouldComponentUpdate` 返回 `false` 时，React 会跳过该组件及其整个子树的 diff。但问题是：开发者必须手动判断每个 props 是否变化，遗漏任何一个就会导致不必要的渲染，写错了还会导致 UI 不更新。
**2. PureComponent（浅比较自动化）**
```javascript theme={null}
class ListItem extends React.PureComponent {
render() {
return {this.props.item.name}
;
}
}
```
`React.PureComponent` 自动对 props 和 state 做浅比较（shallow compare），省去了手写 `shouldComponentUpdate` 的麻烦。但浅比较有天然缺陷——如果父组件传入新的数组或对象引用（即使内容相同），浅比较会认为"变了"，导致无效渲染。
**3. Batching（批处理合并更新）**
```javascript theme={null}
// React 事件回调内：自动批处理
handleClick() {
this.setState({ a: 1 });
this.setState({ b: 2 });
// 只触发一次渲染
}
// setTimeout 内：不批处理！
handleClick() {
setTimeout(() => {
this.setState({ a: 1 });
this.setState({ b: 2 });
// 触发两次渲染！
}, 0);
}
```
React 15 的批处理仅限于 React 自己管理的事件回调。在 `setTimeout`、`Promise` 等原生异步上下文中，每次 `setState` 都会立即触发一轮完整渲染。
### 为什么这些优化不够？
```text theme={null}
shouldComponentUpdate → 手动维护成本高，容易出错
PureComponent → 浅比较无法处理复杂数据结构
Batching → 只在 React 事件内生效，异步上下文无效
本质问题：这些优化都在"减少工作量"，但没有解决"工作方式"的根本缺陷
Stack Reconciler 依然是同步递归 → 依然一口气跑完 → 依然阻塞主线程
```
> [!TIP]
>
> React 15 的 Stack Reconciler 就像一个必须一口气跑完全程的马拉松选手——`shouldComponentUpdate` 相当于给选手"抄近路"的机会，`PureComponent` 相当于"自动识别近路"，`Batching` 相当于"把多次出发合并成一次"。但无论怎么优化，选手依然不能中途停下来休息。React 16 的 Fiber 就像换了新规则——每跑 100 米就可以在路边歇一歇（时间切片），休息够了再接着跑，从此不再怕大型应用的"马拉松"。
> [!NOTE]
>
> React 15 的 Stack Reconciler 用同步递归做 diff，`shouldComponentUpdate`、`PureComponent` 和 Batching 只能"减少工作量"，无法改变"必须一口气跑完"的根本限制——React 16 的 Fiber 架构才是真正的解法。
***
## Q3: React 18 的并发模式是如何工作的？
React 18 最核心的突破是将并发特性（Concurrent Features）从实验阶段正式落地。React 官方博客对并发能力的描述是：不必在"快速响应用户输入"和"渲染大量数据"之间二选一\[3]。它的本质是赋予 React **中断并优先处理更重要渲染任务**的能力。
```text theme={null}
┌───────────────────────────────────────────────┐
│ 浏览器主线程 │
└──────┬───────────────────────────────┬────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ 低优任务 (A) │ │ 高优任务 (B) │
│ 渲染大列表 │ │ 用户输入框打字 │
└──────┬───────┘ └──────┬───────┘
│ │
│ (执行一半，耗时 5ms) │
├───────────────────────────────┤ ← React 调度器发现高优交互
│ 中断当前 A 任务的渲染 │
│ │
│ ▼
│ ┌──────────────┐
│ │ 执行 B 任务 │
│ │ 更新输入框 UI │
│ └──────┬───────┘
│ │
│ (B 任务执行完毕) │
├───────────────────────────────┘ ← 恢复现场
▼
┌──────────────┐
│ 恢复任务 (A) │
│ 继续渲染大列表 │
└──────────────┘
```
```tsx theme={null}
// 并发更新的核心 API
import { useState, useDeferredValue, useTransition } from "react";
// 方式一：useDeferredValue，适合值来自 props、无法改更新调用方的场景
function SearchList({ allItems }) {
const [query, setQuery] = useState("");
const deferredQuery = useDeferredValue(query);
const isStale = query !== deferredQuery;
const filtered = allItems.filter((item) => item.name.includes(deferredQuery));
return (
<>
setQuery(e.target.value)} />
{filtered.map((item) => (
- {item.name}
))}
);
}
// 方式二：startTransition，适合自己能控制 setState 的场景
function FilterPanel({ allItems }) {
const [list, setList] = useState(allItems);
const [isPending, startTransition] = useTransition();
const handleFilter = (keyword) => {
// 非紧急更新：可以被高优先级更新打断
startTransition(() => {
setList(allItems.filter((item) => item.name.includes(keyword)));
});
};
return (
);
}
```
> [!WARNING]
>
> React 18 默认启用并发渲染能力，但不会把所有更新都当成低优先级。只有显式调用 `startTransition` 或使用 `useDeferredValue`，某个更新才会被标记为"非紧急任务"；普通 `setState` 走 DefaultLane，仍按普通优先级调度。
> [!TIP]
>
> 并发模式就像医院急诊室的分诊机制。你正在给一个脚踝扭伤的病人（低优的列表渲染）做包扎，突然推车送来一个心脏病发的重症患者（高优的用户输入）。医生（React 调度器）会立即暂停包扎，优先抢救心脏病患者，等抢救结束脱离危险后，再回去把扭伤病人的绷带打完。
***
## Q4: React 16 为什么是一次架构革命？
> [!TIP]
>
> React 16 的架构革命就像工厂流水线的升级。React 15 的流水线一旦开工就不能停——哪怕工人（JS 引擎）已经累得干不动了，也得一口气把所有工序做完（同步递归），产品（UI）才能下线。React 16 把流水线改成了"可暂停"的模式——每做完一道工序（一个 Fiber 节点），就检查一下"下班时间到了没"（shouldYield），到了就暂停，把半成品存好（保存 nextUnitOfWork），明天接着干。同时 Hooks 的引入就像把分散在不同车间的工具（状态、副作用）集中到了一个工具箱里（函数组件），取用更方便。
**1. 16.6ms 的帧预算与同步阻塞**
现代浏览器为了保持 60fps，要求每帧执行时间在 16.6ms 以内。React 15 的 Stack Reconciler 用同步递归对比虚拟 DOM，一旦开始就无法中断。大型应用一次 `setState` 可能占用主线程 100ms+，直接导致掉帧卡顿。
**2. Stack Reconciler 的致命局限**
JavaScript 原生调用栈（Call Stack）是后进先出的结构，无法在中间状态暂停并事后恢复。这意味着 React 15 没有任何办法把一个巨大的更新任务拆成小块，只能一口气跑完。
**3. Fiber 架构的引入**
React 16 彻底抛弃递归算法，引入了基于单链表的 Fiber 架构。每个组件对应一个 Fiber 节点，通过 `child`、`sibling`、`return` 三个指针构建虚拟调用栈，用 `while` 循环替代递归，实现了时间切片（Time Slicing）。
**4. 生命周期的废弃与重塑**
由于 Fiber 允许 Render 阶段的中断和重新执行，旧版带有副作用的生命周期（`componentWillMount`、`componentWillReceiveProps`、`componentWillUpdate`）可能被多次触发。React 从 16.3 起标记废弃，并在 React 17 移除，引入 `getDerivedStateFromProps` 等更纯粹的替代方案。
\*\*5. Hooks 的范式转移 (16.8) \*\*
Hooks 让函数组件拥有了状态管理和副作用处理的能力，逻辑复用从高阶组件（HOC）和 Render Props 的地狱中解放出来。`useState`、`useEffect`、`useMemo` 等 API 极大降低了代码耦合度。
**React 16 解决的核心问题：**
```text theme={null}
问题：同步递归 + 无法中断 = 大型应用卡顿
setState → 同步递归遍历整个组件树 → 主线程被阻塞 100ms → 掉帧卡顿
解决：Fiber 时间切片 — 拆分成微小执行单元，每执行一个就检查剩余时间
setState → 执行一个 Fiber 节点 → 检查时间 → 有剩余继续，没剩余让出主线程 → 下一帧恢复
```
> [!NOTE]
>
> React 16 用 Fiber 链表替代递归调用栈，把"一口气跑完"变成了"跑一段歇一下"，彻底解决了大型应用的主线程阻塞问题。
> [card] React 15 的痛点
>
> 同步递归对比虚拟 DOM，阻塞主线程无法中断；逻辑复用靠高阶组件层层嵌套。就像一个必须一口气跑完全程的马拉松，中途不能停下调整呼吸。
> [card] React 16 的破局
>
> Fiber 时间切片实现可中断渲染，Hooks 实现函数式逻辑复用，Error Boundaries 实现优雅降级。就像修了服务区的接力赛跑，可以停顿、可以重试、可以交接。
> [!TIP]
>
> 回答时先说"为什么"（同步递归阻塞主线程），再说"怎么解决"（Fiber 时间切片）。想听的是你对架构演进背后驱动力的理解，而不是流水账背版本号。
***
## Q5: React 16 vs 18 vs 19 有哪些关键差异？
> [!TIP]
>
> React 16 就像第一代智能手机——终于能中断任务了（Fiber 时间切片），但还不知道该优先处理什么。React 18 就像第二代——有了智能分屏（并发模式），可以一边看视频一边回消息（高优任务打断低优任务），而且所有应用的通知都统一管理了（Automatic Batching）。React 19 就像第三代——有了 AI 助手（React Compiler），它能自动帮你整理相册（自动 memoization），你再也不用手动分类了。
### 版本演进的底层逻辑
React 每次大版本升级都不是孤立的 API 增加，而是在解决前一版本遗留的架构瓶颈。理解这个演进逻辑，比记住版本号更重要。
### 基础梳理
| 维度 | React 16 | React 18 | React 19 |
| - | - | - | - |
| **渲染架构** | Fiber（可中断） | 并发渲染（Concurrent） | 并发渲染 + 可选 React Compiler（独立构建插件） |
| **批处理** | 仅 React 事件内批处理 | 自动批处理（含 setTimeout/Promise） | 同 18，编译器可辅助减少重渲染 |
| **SSR** | renderToString | 流式 SSR + Suspense | Server Components 一等公民 |
| **状态管理** | useState/useReducer | + useTransition/useDeferredValue | + use() hook + Actions |
| **事件系统** | 代理到 document | 代理到 Root Node | 同 18 |
### 专家视角深度剖析
很多人只能背诵上面的表格，但实际更在意的是：**React 每次大版本升级背后的技术驱动力是什么？**
React 16 的核心驱动力是**解决同步阻塞**。Fiber 架构把递归变成迭代，为时间切片奠定了基础。但 Fiber 只是"能中断"，并没有告诉 React "该中断什么、优先处理什么"。
React 18 补上了这块拼图。Andrew Clark 在 Lanes 设计 PR 中说明了从 ExpirationTime 到 Bitmask 的演进动机：ExpirationTime 用一个数字表示优先级，只能做线性比较；Lanes 用位图表示多个优先级通道，可以通过位运算快速判断任务批次和插队关系\[4]。这让调度器可以根据任务类型（用户输入 > 过渡动画 > 数据获取）决定中断策略。同时，自动批处理（Automatic Batching）解决了 React 17 中 `setTimeout` 和 `Promise` 内 `setState` 不批处理的历史包袱。
React 19 的方向是**减少手写优化与异步样板**。Sebastian Markbage 在 React Summit 2020 的演讲中阐述了 React Server Components 的设计动机：传统 React 应用把所有代码发给客户端；Server Components 只发送客户端需要的代码，同时直接访问后端资源\[5]。需要区分的是，React Compiler（原 React Forget）是独立构建插件，不是 React 19 运行时内置特性；Actions 和 `use()` 才是 React 19 正式提供的能力。`use()` 统一了 Promise、Context 的读取方式，Actions 简化了异步状态与表单处理。
```tsx theme={null}
// React 19 的 use() hook — 统一资源消费
function UserProfile({ userPromise }) {
// use() 可以在条件语句和循环中使用（打破 Hooks 规则）
// 注意：Promise 要来自缓存或上层，不能在渲染里直接新建，否则每次渲染都会重新请求
const user = use(userPromise); // 自动与 Suspense 配合
return {user.name}
;
}
// React 19 的 Actions — startTransition 支持 async 函数
function UpdateName() {
const [isPending, startTransition] = useTransition();
const [error, setError] = useState(null);
const handleSubmit = (name) => {
startTransition(async () => {
const error = await updateName(name);
if (error) {
setError(error);
return;
}
redirect("/profile");
});
};
}
```
***
## Q6: React 事件系统为什么从 document 改到了 Root Node？
> [!TIP]
>
> React 16 的事件委托就像在一栋大楼门口装了一个大喇叭——所有楼层的所有事件都通过这一个喇叭广播（代理到 document），如果大楼里同时有两个公司（微前端多版本共存），两家的广播会互相干扰。React 17+ 改成了每家公司配一个对讲机（代理到各自 Root Node），各自收各自的信号，互不干扰。
### 合成事件与事件委托
React 的合成事件系统是其跨平台能力的基石——通过在顶层统一代理所有 DOM 事件，React 可以在不同渲染器（DOM、React Native）中提供一致的事件模型。
**React 16 的事件委托：**
React 16 将所有事件统一代理到全局 `document` 上。这在单应用时代没问题，但微前端场景下，多个 React 版本共存时，事件冒泡顺序会变得不可预测。
**React 17 的改变：**
从 React 17 开始，事件不再代理到 `document`，而是代理到该 React 应用渲染的根节点（Root Node，通常是 `div#root`）。这支持了多个 React 版本在同一页面共存。
```javascript theme={null}
// React 16：事件代理到 document
document.addEventListener("click", (e) => {
// 所有 React 应用的点击事件都在这里处理
dispatchEvent(e); // React 内部的合成事件分发
});
// React 17+：事件代理到 root node
rootNode.addEventListener("click", (e) => {
// 只处理该 React 应用的事件
dispatchEvent(e);
});
```
**关键区别：**
| 场景 | React 16 | React 17+ |
| - | - | - |
| 事件代理节点 | document | Root Node |
| 微前端多版本共存 | 事件冲突 | 各自独立 |
| stopPropagation 影响范围 | 影响所有 React 应用 | 只影响当前应用 |
> [!TIP]
>
> 微前端项目中，如果父子应用使用不同 React 版本，要注意事件冒泡顺序的变化。React 18 子应用的 `onClick` 会在 Root Node 层触发，之后才冒泡到 `document` 触发父应用 React 16 的监听器。
***
## Q7: React 生命周期经历了哪些变化？
> [!TIP]
>
> React 15 的生命周期就像一部严格按剧本演出的舞台剧——每个演员（组件）在固定的时间点说固定的台词（componentWillMount、componentDidMount 等），顺序绝对不能乱。React 16 的 Fiber 打破了这个规则——导演（调度器）可能会喊"停！这段重来！"（Render 阶段中断重试），所以演员不能在排练阶段（Render）做不可逆的事（副作用）。Hooks 时代更像即兴表演——没有固定剧本，演员根据当前场景（依赖数组）灵活决定什么时候行动（useEffect），同一个表演可以同时涵盖"开场、中场互动、谢幕"（一个 useEffect 覆盖多个生命周期）。
### 生命周期演进的底层逻辑
React 生命周期的每一次变化都不是孤立的 API 调整，而是底层架构变革的必然结果。理解这个演进逻辑，比记住每个生命周期方法的调用时机更重要。
### React 15 生命周期
React 15 的生命周期围绕类组件的挂载、更新和卸载三个阶段设计，整体流程是同步且线性的：
```text theme={null}
挂载阶段（Mounting） 更新阶段（Updating） 卸载阶段（Unmounting）
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ componentWillMount │ │ componentWillReceiveProps│ │ componentWillUnmount│
│ ↓ │ │ ↓ │ └───────────────────┘
│ render() │ │ shouldComponentUpdate│
│ ↓ │ │ ↓ │
│ componentDidMount │ │ componentWillUpdate │
└───────────────────┘ │ ↓ │
│ render() │
│ ↓ │
│ componentDidUpdate │
└───────────────────┘
```
```javascript theme={null}
class UserProfile extends React.Component {
// 1. 挂载：组件即将插入 DOM（已被废弃）
componentWillMount() {
console.log("componentWillMount - DOM 不存在，不能做 DOM 操作");
}
// 2. 挂载：组件已插入 DOM
componentDidMount() {
console.log("componentDidMount - 可以安全地做 DOM 操作和数据请求");
this.fetchUser(this.props.userId);
}
// 3. 更新：父组件传入新 props（已被废弃）
componentWillReceiveProps(nextProps) {
if (nextProps.userId !== this.props.userId) {
this.setState({ loading: true });
}
}
// 4. 更新：判断是否需要重新渲染
shouldComponentUpdate(nextProps, nextState) {
return nextProps.userId !== this.props.userId;
}
// 5. 更新：即将开始重新渲染（已被废弃）
componentWillUpdate(nextProps, nextState) {
console.log("componentWillUpdate - render 之前");
}
// 6. 更新：渲染完成后
componentDidUpdate(prevProps, prevState) {
if (prevProps.userId !== this.props.userId) {
this.fetchUser(this.props.userId);
}
}
// 7. 卸载：组件即将从 DOM 移除
componentWillUnmount() {
console.log("componentWillUnmount - 清理定时器、取消订阅");
}
render() {
return {this.state.user?.name}
;
}
}
```
### React 16 生命周期
React 16 引入 Fiber 架构后，Render 阶段可以被中断和重新执行。如果生命周期方法有副作用（如修改 state、操作 DOM），就会在中断恢复时被重复触发，导致不可预测的 bug。因此 React 16.3 废弃了三个带副作用的生命周期，引入了两个更"纯粹"的替代方案。
```text theme={null}
挂载阶段（Mounting） 更新阶段（Updating） 卸载阶段（Unmounting）
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ constructor() │ │ getDerivedStateFromProps│ │ componentWillUnmount│
│ ↓ │ │ ↓ │ └───────────────────┘
│ getDerivedStateFromProps│ │ shouldComponentUpdate│
│ ↓ │ │ ↓ │
│ render() │ │ render() │
│ ↓ │ │ ↓ │
│ getSnapshotBeforeUpdate│ ← 新增│ getSnapshotBeforeUpdate│ ← 新增
│ ↓ │ │ ↓ │
│ componentDidMount │ │ componentDidUpdate │
└───────────────────┘ └───────────────────┘
```
**新增的两个生命周期：**
```javascript theme={null}
class ChatList extends React.Component {
// 替代 componentWillMount + componentWillReceiveProps
// 纯函数：只根据 props/state 计算返回值，没有副作用
static getDerivedStateFromProps(nextProps, prevState) {
if (nextProps.userId !== prevState.prevUserId) {
return {
prevUserId: nextProps.userId,
messages: [], // 重置消息列表
};
}
return null; // 不需要更新 state
}
// 替代 componentWillUpdate
// 在 DOM 更新前获取快照信息（如滚动位置），传递给 componentDidUpdate
getSnapshotBeforeUpdate(prevProps, prevState) {
if (prevProps.messages.length < this.props.messages.length) {
const list = this.listRef.current;
return list.scrollHeight - list.scrollTop; // 返回滚动偏移量
}
return null;
}
// 收到 getSnapshotBeforeUpdate 的返回值作为 snapshot 参数
componentDidUpdate(prevProps, prevState, snapshot) {
if (snapshot !== null) {
const list = this.listRef.current;
list.scrollTop = list.scrollHeight - snapshot; // 恢复滚动位置
}
}
render() {
return {/* 消息列表 */}
;
}
}
```
### React 15 vs 16 生命周期对比表
| 阶段 | React 15 | React 16 | 变化原因 |
| - | - | - | - |
| 挂载 - 初始化 | `componentWillMount` | `constructor()` | `componentWillMount` 中 setState 不会触发额外渲染，直接用 constructor 替代 |
| 挂载 - 初始化 | `componentWillMount` | `getDerivedStateFromProps` | 纯函数，无副作用，不会被中断重复触发 |
| 更新 - props 变化 | `componentWillReceiveProps` | `getDerivedStateFromProps` | 挂载和更新统一用同一个静态方法 |
| 更新 - 渲染前 | `componentWillUpdate` | `getSnapshotBeforeUpdate` | Commit 阶段执行，只读 DOM 快照，不修改 state |
| 更新 - 渲染后 | `componentDidUpdate` | `componentDidUpdate` | 无变化，已在 Commit 阶段，安全 |
| 卸载 | `componentWillUnmount` | `componentWillUnmount` | 无变化，已在 Commit 阶段，安全 |
### 为什么 React 16 废弃了旧生命周期？
核心原因在于 Fiber 架构将渲染分为两个阶段：
```text theme={null}
Render 阶段（可中断） Commit 阶段（不可中断）
┌──────────────────────────┐ ┌──────────────────────────┐
│ getDerivedStateFromProps │ │ componentDidMount │
│ shouldComponentUpdate │ │ componentDidUpdate │
│ render │ │ getSnapshotBeforeUpdate │
│ │ │ componentWillUnmount │
│ 可能执行多次！ │ │ 只执行一次 │
│ 中断 → 丢弃 → 重新开始 │ │ 一旦开始就不会中断 │
└──────────────────────────┘ └──────────────────────────┘
```
`componentWillMount`、`componentWillReceiveProps`、`componentWillUpdate` 都处于 Render 阶段。如果在这些方法中有副作用（发起网络请求、修改全局变量、手动修改 DOM），中断恢复时副作用会被重复执行——发两次请求、改两次 DOM、导致数据错乱。
React 16 的策略是：Render 阶段只允许纯计算（`getDerivedStateFromProps` 返回新 state、`getSnapshotBeforeUpdate` 返回快照），所有副作用全部放到 Commit 阶段（`componentDidMount`、`componentDidUpdate`）。
### Hooks 生命周期
Hooks 时代没有显式的生命周期方法，但 `useEffect` 和 `useLayoutEffect` 覆盖了所有生命周期场景：
```javascript theme={null}
import { useEffect, useLayoutEffect } from "react";
function UserProfile({ userId }) {
// 等价于 componentDidMount + componentDidUpdate + componentWillUnmount
useEffect(() => {
console.log("组件挂载或 userId 变化后执行");
fetchUser(userId);
// 返回的清理函数等价于 componentWillUnmount
// 且在下次 effect 执行前也会先清理上一次的
return () => {
console.log("清理上一次 effect 或组件卸载");
};
}, [userId]); // 依赖数组：只有 userId 变化时才重新执行
// useLayoutEffect vs useEffect 的区别：
// useEffect - 浏览器绘制后异步执行（不阻塞渲染）
// useLayoutEffect - DOM 更新后、浏览器绘制前同步执行（阻塞渲染）
useLayoutEffect(() => {
// 适合读取 DOM 布局并同步修改（避免闪烁）
const rect = ref.current.getBoundingClientRect();
setTooltipPosition(rect.top);
}, []);
return ...
;
}
```
**useEffect vs useLayoutEffect 执行时机：**
```text theme={null}
setState 触发
│
▼
React 计算新虚拟 DOM
│
▼
更新真实 DOM
│
├──────────────────────────────────┐
▼ ▼
useLayoutEffect（同步，阻塞绘制） 浏览器绘制（Paint）
│ │
▼ ▼
执行完毕 useEffect（异步，不阻塞绘制）
│ │
▼ ▼
浏览器绘制 执行完毕
```
> [!WARNING]
>
> * `useEffect` 在浏览器完成绘制后异步执行，不会阻塞用户看到画面。适合大多数副作用（数据请求、日志、订阅）。
> * `useLayoutEffect` 在 DOM 更新后、浏览器绘制前同步执行。适合需要读取 DOM 布局并同步修改的场景（如定位 tooltip）。如果误用 `useLayoutEffect` 做耗时操作，会阻塞渲染导致页面卡顿。
> * 测试环境（Jest + jsdom）中 `useLayoutEffect` 会报 warning，因为测试环境没有真正的浏览器绘制。
> [!NOTE]
>
> React 生命周期从 15 的同步线性模型演进到 16 的可中断双阶段模型，本质原因是 Fiber 允许 Render 阶段中断重试，副作用必须全部移到 Commit 阶段；Hooks 用 `useEffect` 统一了生命周期概念，用依赖数组控制执行时机。
### Function Component vs Class Component
### 范式转移的本质
React 组件经历了从 Class Component 到 Function Component 的范式转移。Dan Abramov 在 Hooks RFC 中指出："Classes are confusing for both people and machines — `this` binding can be confusing, and there's no reliable way to extract reusable behavior between components"\[1]。理解两者的本质区别，是理解 React 为什么最终拥抱 Hooks 的前提。
**两种组件的本质区别：**
| 维度 | Class Component | Function Component |
| - | - | - |
| **本质** | 一个 ES6 Class 实例，有生命周期方法 | 一个纯函数，接收 props 返回 JSX |
| **状态管理** | `this.state` + `this.setState` | `useState` / `useReducer` |
| **副作用** | 生命周期方法（`componentDidMount` 等） | `useEffect` / `useLayoutEffect` |
| **逻辑复用** | HOC / Render Props（层层嵌套） | 自定义 Hook（扁平组合） |
| **this 绑定** | 需要手动处理 `this` 指向问题 | 没有 `this`，不存在绑定问题 |
| **代码量** | 样板代码多（constructor、bind、生命周期） | 样板代码少，更简洁 |
| **可测试性** | 需要实例化类，测试生命周期交互 | 纯函数入参出参，天然易测 |
**为什么 Class Component 被淘汰？**
```text theme={null}
Class Component 的三大痛点：
1. this 绑定地狱
constructor 里 bind、render 里 bind、onClick 里箭头函数……
一个组件 10 个事件处理函数 = 10 次 bind
2. 逻辑复用困难
想复用"监听窗口大小"的逻辑 → HOC 包一层
想复用"鼠标位置追踪"的逻辑 → 再包一层
→ "包装地狱"（Wrapper Hell）
3. 生命周期方法不内聚
componentDidMount 里发请求 + 订阅 + 设置定时器
componentWillUnmount 里清理订阅 + 清理定时器
同一个逻辑分散在两个生命周期方法中 → 难以理解和维护
```
**Function Component 的优势：**
```javascript theme={null}
// Class Component：同一个逻辑分散在多个生命周期中
class WindowWidth extends React.Component {
state = { width: window.innerWidth };
componentDidMount() {
window.addEventListener("resize", this.handleResize);
}
componentWillUnmount() {
window.removeEventListener("resize", this.handleResize);
}
handleResize = () => {
this.setState({ width: window.innerWidth });
};
render() {
return 窗口宽度: {this.state.width}
;
}
}
// Function Component：同一个逻辑集中在一处
function WindowWidth() {
const [width, setWidth] = useState(window.innerWidth);
useEffect(() => {
const handleResize = () => setWidth(window.innerWidth);
window.addEventListener("resize", handleResize);
return () => window.removeEventListener("resize", handleResize);
}, []);
return 窗口宽度: {width}
;
}
// 逻辑复用：提取为自定义 Hook，任何组件都能用
function useWindowWidth() {
const [width, setWidth] = useState(window.innerWidth);
useEffect(() => {
const handleResize = () => setWidth(window.innerWidth);
window.addEventListener("resize", handleResize);
return () => window.removeEventListener("resize", handleResize);
}, []);
return width;
}
// 使用：一行代码复用逻辑
function Dashboard() {
const width = useWindowWidth();
return 当前宽度: {width}
;
}
```
> [!NOTE]
>
> Class Component 用 Class 实例承载状态和生命周期，但 this 绑定、逻辑复用和生命周期分散是三大痛点；Function Component 用纯函数 + Hooks 实现相同能力，代码更简洁、逻辑更内聚、复用更扁平——这就是 React 16.8 引入 Hooks 后 Class Component 逐渐被淘汰的根本原因。
### 为什么要写 this.handleClick = this.handleClick.bind(this)
### JavaScript this 绑定与 React 的碰撞
Class Component 中最经典的"坑"之一：事件处理函数中的 `this` 丢失问题。这道题考察的是你对 JavaScript `this` 绑定规则的理解深度。
**Class Component 的 this 丢失问题：**
```javascript theme={null}
class Button extends React.Component {
handleClick() {
console.log(this); // undefined！this 丢失了
}
render() {
return ;
}
}
```
**为什么 `onClick={this.handleClick}` 会丢失 this？**
```text theme={null}
关键：this 的值由"调用方式"决定，不是由"定义方式"决定
render() 中：