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

一、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 的诞生解决了类组件长期以来的痛点。

为什么要重构？

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

优缺点对比

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

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

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

4. 自定义 Hook 与“状态解耦”

自定义 Hook

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

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

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

1. 逻辑独立：将复杂的逻辑（倒计时、分页、表单验证）封装在 Hook 中。
2. 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）。

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

4. Fiber 架构核心知识点

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

A. Fiber 对象的数据结构

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

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

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

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

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

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

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 会立即暂停手头的活，优先处理点击反馈。

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

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

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

面试点提醒：这种架构的核心目标是解决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 + PriorityOffsetExpirationTime=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是“多车道”**，React 可以根据需要开启或关闭特定的车道，实现更复杂的并行与重排逻辑。