获课：jzit.top/14863/

# 从0实现React18：手写Fiber架构，彻底吃透React底层运行原理

## 为什么要理解Fiber

很多前端开发者用React多年，却依然搞不清楚状态更新时页面究竟发生了什么。常见的认知是“虚拟DOM diff决定哪里变化”，但React18早已不是这么简单。当你调用setState，整个应用并不会“暴力递归”重新渲染——这背后，是一套名为Fiber的架构在精密调度。

Fiber不是新词，但真正理解它的人不多。它不是一个具体的算法，而是一种**数据结构 + 调度策略**的重新设计。如果说旧版React像一次“无法打断的完整手术”，Fiber就像“可暂停、可恢复的微任务队列”。

## 从递归到循环：架构的转折

在React16之前，协调过程依赖递归调用。一旦开始渲染，浏览器就无法响应用户点击或输入，因为主线程被长期占用。对于复杂应用，这种“同步不可中断”的模型直接导致了掉帧和卡顿。

Fiber架构的核心转变，就是**将递归转化为可中断的循环**。每个组件不是被“执行完就销毁”，而是被描述为一个Fiber节点。这个节点保存了组件类型、props、状态、以及指向上级、下级、兄弟的指针。通过这三条指针，React得以在树中自由穿梭——即便在某处暂停，也能记住“刚刚处理到哪里”。

## 工作单元与双缓冲

手写一个简易Fiber时，你会发现最巧妙的并非节点本身，而是**工作单元**的概念。React会在任务队列中逐个取出Fiber节点进行处理，每个节点处理完就询问：“还有剩余时间吗？”如果有，继续；如果没有，交还主线程，等待下一帧再继续。

这种切片式执行，让高优先级更新（如动画或输入）能插队到低优先级渲染之前。

与此同时，React维护着两棵Fiber树——当前屏幕显示的current树，和内存中构建的workInProgress树。所有更新先在workInProgress上完成，当整棵树处理完毕，一次commit将新树“拍”到屏幕上。这种双缓冲机制保证了界面切换的完整性，用户绝不会看到“渲染到一半”的画面。

## 副作用与生命周期的新身份

在Fiber架构下，类组件的生命周期方法被重新定义。原本的componentDidMount、componentDidUpdate等，如今被归类为“副作用”（effects）。React不会在构建阶段立刻执行它们，而是把副作用打上标记，挂在Fiber节点的effectList链表中，等到commit阶段统一处理。

这解释了为什么在并发模式下，某些生命周期会被标记为不安全——因为它们可能在构建阶段被多次调用，而副作用链表的设计就是为了解决这种不确定性。

## 理解Fiber后，你获得了什么

真正吃透Fiber，并不会让你立刻写出更漂亮的UI，但它会彻底改变你对“性能优化”的认知。useMemo和React.memo不再是“哪里慢就包哪里”的黑魔法，而是你理解调度策略后的主动选择。setState为何有时是同步、有时是批处理，也将不再令人困惑。

从0手写Fiber，本质上是在重新理解“浏览器的时钟”和“React的钟表”如何对齐。当你亲手构建出那三条指针、实现任务切片和提交渲染时，你会意识到：React不是魔法，而是一套精心设计的、与浏览器时间赛跑的调度系统。理解它，你便站在了掌控性能的门槛上。