React 的核心设计理念是什么？并列举三大核心特性。

文章目录

[一、React 核心面试指南：设计理念与架构演进](#一、React 核心面试指南：设计理念与架构演进)
- [🟢 面试题：React 的核心设计理念是什么？并列举三大核心特性。](#🟢 面试题：React 的核心设计理念是什么？并列举三大核心特性。)
- - [1. 核心设计理念：快速响应 (Design for Graceful UI)](#1. 核心设计理念：快速响应 (Design for Graceful UI))
  - [2. 三大核心特性（深度解析）](#2. 三大核心特性（深度解析）)
  - - [I. 完全拥抱函数式编程 (Functional Programming)](#I. 完全拥抱函数式编程 (Functional Programming))
    - [II. Fiber 架构 (The Reconciliation Engine)](#II. Fiber 架构 (The Reconciliation Engine))
    - [III. 调度机制：Lanes 模型（车道模型）](#III. 调度机制：Lanes 模型（车道模型）)
  - [3. 技术细节补充 (面试加分项)](#3. 技术细节补充 (面试加分项))
  - [🏆 总结回答示例 (SOP)](#🏆 总结回答示例 (SOP))
二、从类组件到函数式编程的进化
- [1. 什么是函数式编程 (Functional Programming)?](#1. 什么是函数式编程 (Functional Programming)?)
- - 核心概念：
- [2. 为什么 React 从类组件转向函数式组件？](#2. 为什么 React 从类组件转向函数式组件？)
- - 为什么要重构？
  - 优缺点对比
- [3. 高阶组件 (Higher-Order Component, HOC)](#3. 高阶组件 (Higher-Order Component, HOC))
- [4. 自定义 Hook 与"状态解耦"](#4. 自定义 Hook 与“状态解耦”)
- - [自定义 Hook](#自定义 Hook)
  - [什么是 UI 与状态的"充分解耦"？](#什么是 UI 与状态的“充分解耦”？)
  - 解耦的好处
[三、 React Fiber 架构深度解析](#三、 React Fiber 架构深度解析)
- [1. 什么是 Fiber 架构？](#1. 什么是 Fiber 架构？)
- [2. 为什么需要 Fiber 架构？（背景与痛点）](#2. 为什么需要 Fiber 架构？（背景与痛点）)
- - [React 15 的瓶颈](#React 15 的瓶颈)
- [3. Fiber 解决了哪些问题？](#3. Fiber 解决了哪些问题？)
- [4. Fiber 架构核心知识点](#4. Fiber 架构核心知识点)
- - [A. Fiber 对象的数据结构](#A. Fiber 对象的数据结构)
  - [B. 核心机制：双缓存（Double Buffering）](#B. 核心机制：双缓存（Double Buffering）)
  - [C. 更新的两个阶段（Two Phases）](#C. 更新的两个阶段（Two Phases）)
  - [D. 调度逻辑（Scheduler）](#D. 调度逻辑（Scheduler）)
- [5. Fiber 底层拆解](#5. Fiber 底层拆解)
- - [1. 链表结构的 Fiber Node](#1. 链表结构的 Fiber Node)
  - [2. 双缓冲技术 (Double Buffering)](#2. 双缓冲技术 (Double Buffering))
  - [3. 任务优先级调度 (Scheduler)](#3. 任务优先级调度 (Scheduler))
- 总结：为什么这三个设计缺一不可？
[四、 React 调度系统演进：从 ExpirationTime 到 Lanes 模型](#四、 React 调度系统演进：从 ExpirationTime 到 Lanes 模型)
- [1. 什么是 ExpirationTime 模型？](#1. 什么是 ExpirationTime 模型？)
- [2. 什么是 Lanes 模型？](#2. 什么是 Lanes 模型？)
- [3. Lanes 对比 ExpirationTime 的优点](#3. Lanes 对比 ExpirationTime 的优点)
- - [1. 任务的"解耦"与"批处理" (Batching)](#1. 任务的“解耦”与“批处理” (Batching))
  - [2. 解决"高优先级阻塞"问题](#2. 解决“高优先级阻塞”问题)
  - [3. 更灵活的优先级映射](#3. 更灵活的优先级映射)
  - [4. 性能优化（位运算）](#4. 性能优化（位运算）)
- 总结对比

一、React 核心面试指南：设计理念与架构演进

这份指南将 React 的核心考察点串联成一个有逻辑的体系，旨在帮助你在面试中给出高水平、系统化的回答。

🟢 面试题：React 的核心设计理念是什么？并列举三大核心特性。

1. 核心设计理念：快速响应 (Design for Graceful UI)

React 的终极目标是保持界面的快速响应。它主要通过两个维度解决性能瓶颈：

异步调度 (Time Slicing)： 解决 CPU 瓶颈。通过将耗时任务拆分，确保在进行大计算量更新时，浏览器仍能响应高优事件（如点击、输入），避免界面卡顿。
离屏渲染 (Suspense/Concurrent)： 解决 I/O 延迟。通过并发模式确保在数据加载过程中，用户体验依然顺滑，避免频繁出现整页 Loading 的闪烁。

2. 三大核心特性（深度解析）

I. 完全拥抱函数式编程 (Functional Programming)

演进路径： 从类组件（Class Components）全面转向 Hooks。
解决痛点： * 传统类组件逻辑复用困难（需嵌套 HOC 或 Render Props，导致"嵌套地狱"）。
- this 指向混乱，生命周期逻辑分散（同一个功能的代码散落在 didMount 和 didUpdate 中）。
变革逻辑： React 通过 Hooks 实现了 "UI 与状态的充分解耦"。它提倡通过函数组合而非继承来构建逻辑，使代码更易于测试、压缩和 Tree-shaking。

II. Fiber 架构 (The Reconciliation Engine)

架构升级： 将原先不可中断的递归更新（Stack Reconciler）重构为可中断的循环更新（Fiber Reconciler）。
核心能力： * 数据结构： Fiber 节点作为一个工作单元，存储了组件树的结构及更新计划。
- 可调度性： Fiber 支持任务的优先级、并发和恢复。这是实现"时间切片（Time Slicing）"的底层基石。

III. 调度机制：Lanes 模型（车道模型）

优先级管理演进： * 早期 React 使用 expirationTime（截止时间）来调度，但它难以处理"多个同步任务交织"的复杂场景。
- Lanes 模型： 现采用 Lanes（车道模型），通过位运算来表示优先级。
优势： 能够更精细地处理任务的合并、解耦和插队。确保高优任务（如用户输入）永远先于低优任务（如数据请求、后台渲染）执行。

3. 技术细节补充 (面试加分项)

声明式 UI 与 JSX： JSX 本质是 React.createElement 的语法糖。开发者只需关注"当前状态下的 UI 应该是怎样的（结果）"，由 React 负责处理"如何更新 DOM（过程）"，极大降低了维护成本。
单向数据流： 确保数据变化的可预测性。相比于 Vue 的双向绑定，React 强调"状态提升"与"单向流转"，更适合大型复杂项目中的状态回溯与调试。
虚拟 DOM 的进化与并发： * 虚拟 DOM 是跨平台的基石。
- 对比思考： 尽管 Vue 3 正在探索无虚拟 DOM 的 Vapor Mode 提升极致性能，但 React 坚持使用虚拟 DOM。因为其**并发模式（Concurrent Mode）**需要虚拟 DOM 作为内存中的缓存层，来实现"多版本并行"和"渲染中断"。

🏆 总结回答示例 (SOP)

"React 的核心理念是实现极致的快速响应 。为了达到这一点，它在架构上经历了从 Stack 到 Fiber 的重构，引入了 Lanes 模型来精细化调度任务优先级。

在开发范式上，React 通过 Hooks 彻底拥抱了函数式编程，解决了以往逻辑复用难的问题，实现了 UI 与逻辑的深度解耦。结合声明式 JSX 和 单向数据流 ，React 不仅提供了高效的开发体验，更通过其强大的并发特性，保证了在处理复杂交互时的丝滑性能。"

二、从类组件到函数式编程的进化

这是一份关于 React 演进史、函数式编程、组件重构以及状态解耦的深度解析指南。

1. 什么是函数式编程 (Functional Programming)?

函数式编程是一种声明式的编程范式，它将计算机运算视为数学函数的计算，并极力避免改变状态和使用可变数据。

核心概念：

纯函数 (Pure Function)：对于相同的输入，永远得到相同的输出，且没有副作用（不修改外部变量、不发请求等）。
不可变性 (Immutability)：数据一旦创建就不能修改。如果要改变，就创建一个新的副本。
声明式 (Declarative) ：告诉机器"我想要什么"（如 map、filter），而不是像命令式编程那样告诉机器"每一步具体怎么做"（如 for 循环）。

2. 为什么 React 从类组件转向函数式组件？

在 React 16.8 之前，类组件是处理状态的唯一选择。Hooks 的诞生解决了类组件长期以来的痛点。

为什么要重构？

this 指向问题 ：类组件中必须手动 bind(this)，逻辑复杂时容易导致指向模糊。
逻辑复用困难：HOC（高阶组件）或 Render Props 容易导致"嵌套地狱"。
副作用逻辑分散 ：同一逻辑（如订阅/卸载）被拆分在不同的生命周期（componentDidMount / componentWillUnmount）中，难以维护。
性能优化：函数组件更轻量，更利于 React 团队未来的 AoT 编译和代码压缩优化。

优缺点对比

特性	函数式组件 (Hooks)	类组件 (Class)
代码量	简洁，模板代码少	较冗长，有大量模板代码
逻辑复用	极佳 (Custom Hooks)	较差 (HOC/Mixins)
心智负担	需要理解闭包和 Hooks 规则	需要理解 `this` 和生命周期
学习曲线	上手快，精通难	上手稍慢，概念相对固定

3. 高阶组件 (Higher-Order Component, HOC)

HOC 是一种基于 React 组合特性而形成的设计模式，本质是一个装饰器。

定义：一个函数，接收一个组件并返回一个新的组件。
数学公式 ： W = f ( C ) W = f(C) W=f(C)（ C C C 是原组件， f f f 是函数， W W W 是新组件）。
应用场景 ：权限控制、日志打点、数据注入（如 connect）。
现状：由于 Hooks 不会增加组件层级，大部分 HOC 场景已被自定义 Hooks 取代。

4. 自定义 Hook 与"状态解耦"

自定义 Hook

以 use 开头的函数，内部可以调用其他 Hook，旨在不改变组件结构的情况下共享逻辑。

什么是 UI 与状态的"充分解耦"？

这意味着将"怎么画界面"与"数据怎么变"彻底分开：

逻辑独立：将复杂的逻辑（倒计时、分页、表单验证）封装在 Hook 中。
UI 纯粹 ：React 组件只负责渲染，通过 Hook 获取 { data, loading, error } 并返回 JSX。

解耦的好处

可测试性：可以单独测试逻辑，无需渲染 DOM。
极高复用性：逻辑可以在完全不同的 UI 组件间共享。

想尝试重构吗？

如果你有现有的类组件逻辑，我可以帮你将其重构为优雅的自定义 Hook。

三、 React Fiber 架构深度解析

React Fiber 是 React 16 之后引入的全新核心架构，它本质上是对 React 核心算法（Reconciliation）的重写，旨在显著提升大型应用在复杂场景下的性能表现。

1. 什么是 Fiber 架构？

从不同维度理解，Fiber 具有三重含义：

一种架构（Architecture）： 以前的 React 使用"递归"方式更新，Fiber 改成了 "循环"方式 更新，支持任务的 暂停、恢复与优先级调度。
一种数据结构（Static Data Structure）： 每一个 React 元素（Element）都会对应一个 Fiber 对象。它记录了组件的状态、要执行的操作（Effect Tag）以及与其他节点的关系。
一个工作单元（Unit of Work）： React 在更新时，会将每一个 Fiber 节点看作一个任务单元进行处理。

2. 为什么需要 Fiber 架构？（背景与痛点）

在 React 15 及以前，React 使用的是 Stack Reconciler（栈协调器）。

React 15 的瓶颈

不可中断性： 栈协调器通过递归处理组件树。一旦更新开始，React 就会"一条路走到黑"，直到整个 DOM 树对比完成。
主线程阻塞： 如果组件树很大，JS 执行时间会超过 16.6ms （保持 60fps 帧率所需的上限）。此时浏览器无法处理高优先级的任务，例如：
- 用户输入、点击（Input Response）
- 动画过渡（Animation）
结果： 页面出现卡顿、掉帧，用户感觉操作没有响应。

3. Fiber 解决了哪些问题？

Fiber 的核心目标是实现 增量渲染（Incremental Rendering）。

解决了掉帧问题： 通过将大任务拆分为小任务，确保浏览器每一帧都有时间处理用户输入和动画。
支持优先级： 比如"用户输入"的优先级高于"后台数据列表更新"，Fiber 可以先暂停列表渲染，优先响应输入。
并发能力： 为后续的 Concurrent Mode（并发模式） 打下了基础，使得 React 可以同时处理多个任务流。

4. Fiber 架构核心知识点

Fiber 的工作原理可以总结为："一棵链表树、两个阶段、一种控制权移交"。

A. Fiber 对象的数据结构

Fiber 使用了链表结构来替代之前的递归树，这使得 React 可以随时跳出循环：

return: 指向父节点。
child: 指向第一个子节点。
sibling: 指向右侧第一个兄弟节点。
alternate: 指向"旧"或"新"的对应节点（用于双缓存技术）。

B. 核心机制：双缓存（Double Buffering）

React 内存中维护了两棵 Fiber 树：

Current Tree（当前树）： 屏幕上正在显示的 UI。
WorkInProgress Tree（工作树）： 正在内存中构建、准备更新的树。
一旦 WorkInProgress 树构建完成，React 只需简单地交换指针（将 Root 指向新树），就能完成 UI 替换，极大提高了效率。

C. 更新的两个阶段（Two Phases）

阶段	名称	职责	特点
阶段 1	Reconciliation (协调)	找出哪些节点需要更新（Diff 算法），构建 Fiber 树。	可中断。根据剩余时间（RequestIdleCallback 机制）分片执行。
阶段 2	Commit (提交)	将变更真正应用到 DOM 上，执行生命周期钩子。	不可中断。为保证 UI 一致性，必须一次性完成。

D. 调度逻辑（Scheduler）

React 内部有一个"调度员"。它会检查当前帧是否还有剩余时间：

有剩余时间： 执行下一个 Fiber 任务。
无剩余时间： 将控制权交还给浏览器，请求在下一个空闲时段继续。

这份图片展示了 React Fiber 架构的核心设计理念，解释了 React 如何实现"可中断渲染"这一黑科技。

以下是图片文字的提取及其对应知识点的深度补充：

5. Fiber 底层拆解

1. 链表结构的 Fiber Node

原文： Fiber 把组件树的每个节点表示为一个 Fiber Node，通过 child、sibling、return 指针连接成链表。链表结构天然支持中断后从断点继续遍历，而不用像递归那样依赖调用栈状态。
补充：
- 从递归到循环： 在 React 16 之前（Stack Reconciler），遍历是递归的。一旦开始，除非栈空，否则无法停止。Fiber 将递归改写成了基于 while 循环的模拟帧调度。
- 指针的作用： * child：指向第一个子节点。
  - sibling：指向下一个兄弟节点。
  - return：指向父节点（完成当前节点后返回）。
- 意义： 这种结构让 React 可以随时"存盘"。中断时只需记录当前指针，下一帧直接从该指针继续。

2. 双缓冲技术 (Double Buffering)

原文： React 内存中同时维护 current 树（当前屏幕上显示的内容）和 workInProgress 树（正在构建的新树）。更新时在 workInProgress 树上渐进式工作，完成后一次性把 current 指针指向它。这个过程不会阻塞用户看到中间状态。
补充：
- 图形学借鉴： 这与显卡渲染游戏的原理一致。一帧画面在后台缓冲区（Back Buffer）画好后，瞬间切换到前台（Front Buffer），防止屏幕闪烁或出现残缺画面。
- Fiber 复用： 在构建 workInProgress 树时，React 会尽量复用 current 树中的 Fiber 节点数据，减少内存分配开销。
- 提交阶段（Commit）： 只有当整个 workInProgress 树在内存中完全构建完毕（并在调度允许下），才会进入同步的 Commit 阶段修改真实 DOM。

3. 任务优先级调度 (Scheduler)

原文： Fiber 架构配合 Scheduler 调度器，根据任务紧急程度分配优先级。高优先级任务可以打断低优先级任务，低优先级任务后面再恢复执行------这是递归模型完全做不到的。
补充：
- 优先级分级： React 定义了多个优先级（如 Immediate、UserBlocking、Normal、Low、Idle）。
- 时间分片 (Time Slicing)： 浏览器通常每 16.6ms (60fps) 刷新一次。Scheduler 会在每一帧留出极短的时间（如 5ms）给 React 执行任务。如果时间用完了，React 必须交还控制权给浏览器去处理输入或动画。
- 任务打断： 如果在处理低优先级的数据请求时，用户点击了按钮（高优先级），React 会立即暂停手头的活，优先处理点击反馈。

总结：为什么这三个设计缺一不可？

这三个设计共同形成了一个闭环：

链表结构 提供了"可暂停"的基础。
双缓冲技术 提供了"不穿帮"的保障（用户看不到还没渲染完的中间态）。
任务优先级 提供了"谁先走"的决策大脑。

面试点提醒： 这种架构的核心目标是解决 CPU 密集型任务 （组件过多导致渲染卡顿）和 IO 密集型任务 （网络请求返回快慢不一）对用户体验的影响，最终实现 Concurrent Mode（并发模式）。

Fiber 并不是让 JS 执行变快了，而是通过"合理的任务拆分与调度"，
让页面在执行繁重更新任务时依然能流畅响应用户。它将 React 从"被动等待 JS 执行完"转变为"主动调度资源"的智能框架。

四、 React 调度系统演进：从 ExpirationTime 到 Lanes 模型

在 React 的演进历程中，调度系统（Scheduler）的核心逻辑从 ExpirationTime 模型 升级到了 Lanes 模型（车道模型）。这一转变是 React 为了更精细地控制渲染优先级而进行的架构升级。

1. 什么是 ExpirationTime 模型？

在 React 16 的早期版本中，React 使用 ExpirationTime（过期时间）来衡量任务的优先级。

核心逻辑 ：每个更新任务都会被分配一个 ExpirationTime。
计算公式 ：大致为 E x p i r a t i o n T i m e = C u r r e n t T i m e + P r i o r i t y O f f s e t ExpirationTime = CurrentTime + PriorityOffset ExpirationTime=CurrentTime+PriorityOffset。
优先级判断：过期时间越短，表示任务越紧急，优先级越高。
调度方式：React 会优先处理过期时间最近的任务。如果一个任务即将到期，它会从"异步模式"转为"同步模式"，以防止任务"饿死"（Starvation）。

2. 什么是 Lanes 模型？

从 React 17 开始，React 引入了 Lanes（车道）模型 。它借鉴了"多车道公路"的概念，用一个 32 位的二进制位（bitmask） 来表示不同的优先级。

核心逻辑：每一位（或一组位）代表一种特定的任务类型（如同步优先级、连续交互优先级、默认优先级等）。
位运算 ：通过位运算（如 &、|、~）来快速合并、筛选或删除某些任务集。
任务表现：优先级不再是一个连续的数值，而是一个离散的标识符。

3. Lanes 对比 ExpirationTime 的优点

虽然 ExpirationTime 简单直观，但在处理复杂场景时存在局限性，Lanes 模型解决了以下核心痛点：

1. 任务的"解耦"与"批处理" (Batching)

ExpirationTime：优先级被耦合在了一个时间轴上。如果你想同时处理两个不连续的优先级任务，很难通过一个简单的数值区间来表达。
Lanes ：利用位掩码，可以轻松选择特定的"车道"。例如，你可以同时处理"车道 1"和"车道 3"的任务，而跳过"车道 2"。这使得 优先级合并（Merging Priorities） 变得极其高效。

2. 解决"高优先级阻塞"问题

ExpirationTime：在一个长任务执行期间，如果产生了一个更高优先级的更新，旧模型通常只能处理"大于当前优先级"的所有任务。
Lanes：支持更细粒度的优先级打散。它可以明确地表示："我只想处理 IO 相关的任务，暂时不处理 CPU 密集型任务"，即使它们的过期时间可能重叠。

3. 更灵活的优先级映射

在 ExpirationTime 中，难以表达"IO 等待"这种特殊的优先级（因为它没有明确的过期概念）。Lanes 模型通过不同的位，可以区分：

SyncLane: 同步更新，不可中断。
InputContinuousLane: 连续输入（如滚动、拖拽）。
DefaultLane: 普通的数据请求更新。
IdleLane: 空闲时才执行的任务。

4. 性能优化（位运算）

从计算角度看，操作一个 32 位整数的位运算性能极高，远快于频繁的对象对比或复杂的数学计算。

总结对比

特性	ExpirationTime 模型	Lanes 模型
数据结构	连续的数值 (Integer)	离散的位掩码 (32-bit Bitmask)
优先级表示	数值越小/大代表优先级越高	不同的位代表不同类型的优先级
任务组合	难以组合不连续的任务	完美支持任务集的合并与拆分
灵活性	较低，受限于线性时间轴	极高，支持多维度任务调度

简而言之 ：ExpirationTime 是**"单车道"，大家按时间的先后和紧急程度排队；而 Lanes 是"多车道"**，React 可以根据需要开启或关闭特定的车道，实现更复杂的并行与重排逻辑。