对于每一位 React 开发者而言，UI = f(state) 这个公式或许早已烂熟于心。它如同一块基石，支撑着我们构建的万千组件世界。然而，你是否曾停下来深思：这个看似简单的 f，在 React 的世界里究竟意味着什么？它为何从一个纯粹的函数概念，演变成一套复杂、精妙甚至可以被中断和调度的系统？
这趟探索之旅，将带领我们拨开 React 的层层迷雾，从其设计的"第一性原理"出发，探寻从 Stack 到 Fiber 的架构演进之路。理解这一切，不仅能让你写出更高效、更健壮的 React 应用，更能让你从一个框架的"使用者"，蜕变为一个能洞察其灵魂的"掌控者"。
万物之始：UI = f(state) ------ 重新审视前端框架的本质
所有现代前端框架，无论其 API 如何千变万化，其核心使命都可以被这个公式概括。state 是数据，是"自变量"；UI 是最终呈现给用户的视图，是"因变量"。而 f，则是框架的灵魂------它定义了从数据到视图的映射规则和运行机制。不同框架的 f 实现方式，决定了它们的性格与能力边界。
更新粒度的抉择：React 为何是"应用级"框架？
当 state 发生变化时，框架如何响应？这是区分不同框架"性格"的关键。我们可以根据更新的粒度，将主流框架粗略地分为三类：
- 元素级框架 (如 Svelte) ：通过编译时分析，建立
state与具体 DOM 元素的直接对应关系。当状态改变，它能像外科手术刀一样，精准地只更新那个需要改变的 DOM 节点。 - 组件级框架 (如 Vue) ：它追踪到状态变化影响了哪个组件，然后对该组件进行 VDOM diff，更新组件内的 DOM。这好比给某个区域打上一个精准的补丁。
- 应用级框架 (即 React) ：当任何一个
state改变，React 默认会从应用的根节点开始，重新遍历整个组件树，生成新的 VDOM，再与旧的 VDOM 对比，找出差异并更新。
初看之下，React 的方式似乎最为"笨拙"和低效。一个微小的状态变化，为何要牵动整个应用？这正是 React 设计哲学中的第一个重要权衡。它牺牲了细粒度的自动追踪能力，以此换取了架构上的巨大灵活性和强大的上层能力。正是这种"笨拙"，为后来的"时间切片"和"并发模式"等革命性特性埋下了伏笔。
React 的哲学是：我宁愿多做一些计算（遍历组件树），也要保证整个更新流程是可预测、可控制的。这种控制力，是实现高级调度功能的基础。
历史的十字路口：从 Stack 到 Fiber 的架构演进
在 React 16 之前，那个"笨拙"的更新方式确实带来了性能问题。一次大规模的组件树更新，可能会长时间占用浏览器主线程，导致页面卡顿、掉帧，用户体验急剧下降。React 团队面临一个历史性的抉择：是小修小补，还是彻底重构？他们选择了后者。
两大瓶颈：CPU 与 I/O
React 的演进，始终围绕着解决两大核心瓶颈：
- CPU 瓶颈 ：当应用变得复杂，组件树庞大，一次更新需要进行的 VDOM 计算（即
f(state)的过程）会非常耗时。如果这个过程是同步且不可中断的，主线程就会被阻塞，任何用户交互、动画都将无法响应。 - I/O 瓶颈：网络请求、数据加载等异步操作是现代应用的常态。在等待数据返回时，我们希望 UI 能够优雅地处理加载状态，甚至允许用户进行其他更高优先级的操作（比如关闭弹窗、输入文字），而不是整个应用都"卡死"在等待中。
旧的架构（React 15 及以前），被称为 Stack Reconciler（栈协调器），其更新过程是基于函数调用栈的递归。一旦开始，就必须一条道走到黑，无法中途暂停。这使得解决上述瓶颈变得几乎不可能。
破局之道：可中断的"时间切片"
为了让耗时的更新过程不再阻塞主线程，React 必须找到一种方法，将一个大任务拆分成许多小任务。执行一小段时间后，就把主线程的控制权交还给浏览器，让浏览器有机会去处理更高优先级的任务（如用户输入或页面渲染）。这个机制，就是大名鼎鼎的 Time Slice（时间切片） 。
要实现时间切片，核心前提是：更新过程必须是可中断的 。递归调用栈无法被中断，因此，React 团队必须抛弃它，转而设计一种全新的、基于可中断循环的协调器------这就是 Fiber Reconciler 的诞生。
深入 Fiber 内部：React 的新心智模型
Fiber 不仅仅是一个新名词，它代表了 React 核心算法的彻底重写，也为我们提供了一套全新的理解 React 运行机制的心智模型。
Fiber 不仅仅是"虚拟 DOM"
很多人将 Fiber 与 Virtual DOM 混为一谈，但实际上，Fiber 是 VDOM 在 React 中的一种更高级的实现。一个 Fiber 节点，承载了三重含义：
- 作为静态数据结构：它保存了一个组件的类型（如 FunctionComponent、HostComponent）、props、key 等信息，这与 VDOM 节点类似。
- 作为动态工作单元：在更新过程中，每个 Fiber 节点都是一个独立的工作单元。React 可以处理一个或多个 Fiber 节点，然后暂停，稍后再回来继续处理。
- 作为树状结构中的一环 ：Fiber 节点通过
child、sibling和return（指向父节点）指针，构成了一棵链表树。这使得 React 可以不依赖递归调用栈，而是通过遍历这棵链表树来执行更新。
想象一下，当你的组件树更新时，React 不再是深陷于一个巨大的函数调用，而是在一个精心构建的"任务地图"（Fiber 树）上从容地漫步，随时可以停下来看看风景（交出主线程），然后再继续前行。
JavaScript
// 对于这样的 JSX 结构
function App() {
return (
<div>
<p>Hello</p>
<span>World</span>
</div>
);
}
// React 内部会构建一个类似这样的 Fiber 树结构 (概念上的)
// App Fiber --(child)--> div Fiber --(child)--> p Fiber --(sibling)--> span Fiber
// 每个节点都有一个 return 指针指回其父节点双缓存魔法：current 与 workInProgress
如果更新过程可以被中断，那么用户会不会看到一个"更新了一半"的残缺 UI？为了解决这个问题，React 引入了图形学中常见的"双缓存"技术。
在任何时候，React 内部都维护着两棵 Fiber 树：
current树：这棵树对应着当前屏幕上已经渲染的 UI。它是稳定、不可变的。workInProgress(wip) 树 ：这是一棵在内存中构建的"草稿"树。所有新的更新、计算和状态变更都发生在这棵树上。这个过程就是可中断的 Render 阶段。
当 wip 树完全构建完毕后，React 会进入一个短暂且不可中断的 Commit 阶段 。在这个阶段，React 会用 wip 树一次性地替换掉 current 树，并把计算出的变更应用到真实的 DOM 上。这个原子性的切换操作，确保了用户永远不会看到不完整的 UI。
这个过程就像一位画家拥有两块画板。他在一块备用画板（wip 树）上精心绘制下一帧的画面，无论花费多长时间，观众看到的始终是当前展示的那块画板（current 树）。直到画家完成所有创作，他才会瞬间将两块画板调换。
实践与思考：设计原理如何指导我们编码？
理解了这些底层原理，我们就能更深刻地领悟 React API 设计背后的"为什么"，从而在日常开发中做出更明智的决策。
理解 key 的真正意义
为什么在渲染列表时，React 总是强调要提供一个稳定且唯一的 key？因为 key 是 React 在 VDOM diff 过程中识别节点的"身份证"。在对比新旧两棵树的子节点列表时，React 正是依靠 key 来判断一个元素是"移动"了，还是"被删除并新增"了。没有 key，React 只能进行效率低下的逐个对比，这会引发不必要的 DOM 操作和组件状态丢失。这正是其"应用级"更新策略下，给开发者用于优化的一个重要"后门"。
拥抱单向数据流与组合
React 的数据流是严格单向的：数据（state/props）从父组件流向子组件。当子组件需要改变数据时，它必须通过调用父组件传递下来的回调函数来"通知"父组件更新状态。这种看似繁琐的模式，保证了数据源的唯一性和可追溯性，使得在复杂的应用中调试和推理状态变化变得异常清晰。这也是 UI = f(state) 公式的直接体现：state 在哪里，更新的逻辑就在哪里。
同时，React 官方文档强调"组合优于继承"。通过 props 传递组件或 JSX，我们可以构建出极其灵活和可复用的 UI 结构，这比传统的类继承模式要强大得多。
为什么我们需要 useEffect 的依赖数组？
这恰恰是 React "应用级"更新策略的直接产物。因为 React 不会自动追踪一个副作用函数（useEffect 的回调）内部依赖了哪些 state 或 props。每次组件渲染，它都会重新执行函数组件的整个函数体。如果我们不提供依赖数组，React 就不知道这个副作用是否需要重新执行。
依赖数组就是我们开发者给 React 的一个明确指令："只有当这个数组里的值发生变化时，你才需要重新运行这个 effect"。这与 Vue 等框架的自动依赖追踪形成了鲜明对比，再次体现了 React 将部分优化责任交给开发者的设计哲学。
结语：从"使用者"到"掌控者"
从一个简单的 UI = f(state) 公式出发，我们一路探索到其背后庞大而精密的 Fiber 架构。我们看到，React 的每一个设计决策，都是在各种限制和目标之间做出的精妙权衡：
- 为了拥抱 JSX 的灵活性，它放弃了模板语言的编译时优化。
- 为了实现可中断渲染和并发更新，它选择了看似"笨拙"的应用级更新模型，并重构了整个核心。
- 为了保证更新的可预测性，它把一部分性能优化的"开关"（如
key,memo, 依赖数组）交到了开发者手中。
因此，下一次当你写下 useState，或是为 useEffect 传入依赖数组时，希望你能记起，你不仅仅是在调用一个 API。你是在与一个为了追求极致用户体验和开发灵活性而构建的、这个时代最复杂的 UI 运行时之一进行对话。