深入理解React Fiber架构：从栈调和到时间切片

深入理解React Fiber架构：从栈调和到时间切片

上个月排查一个React项目的卡顿问题，打开Chrome DevTools一看，主线程被JS占满了，长任务超过200ms，用户点击按钮半秒没反应。

当时我的第一反应是：组件渲染太多了，用React.memo优化一下。优化完确实好了一点，但问题没根治。

后来深挖下去才发现，问题不在组件数量，而在React的调和机制------旧版React用的是同步递归调和，一旦开始就不会停下来。这意味着如果你的组件树很大，一次更新就会霸占主线程很久，用户的交互请求只能排队等。

React Fiber就是为了解决这个问题而生的。今天聊聊Fiber到底是什么，以及它是怎么让React"呼吸"的。

---

旧版React的调和问题

先看旧版React（React 15及之前）是怎么处理更新的。

栈调和（Stack Reconciler）

旧版React用递归遍历虚拟DOM树，对比新旧节点，找出差异，然后一次性更新真实DOM。

// 简化版：旧版调和的递归过程
function reconcile(vnode, parent) {
  // 创建或更新DOM节点
  const dom = createOrUpdateDOM(vnode);
  
  // 递归处理子节点
  vnode.children.forEach(child => {
    reconcile(child, dom);
  });
}

问题在哪？递归一旦开始，就没法暂停。

假设你的组件树有1000个节点，更新开始后，React会一口气遍历完所有1000个节点，中间不会让出主线程。这期间用户点击、输入、滚动------所有交互都被阻塞了。

这就像你妈让你打扫整个房子，你从客厅开始，一路扫到卧室、厨房、阳台......中间你爸喊你接个电话，你说"等我把整个房子打扫完再说"。你爸只能等着。

为什么这是个大问题？

随着前端应用越来越复杂，组件树动辄几千个节点。一次状态更新可能触发大范围的重新渲染，同步调和导致的卡顿越来越明显。

特别是在动画场景下，每帧只有16ms的预算（60fps），如果JS执行超过16ms，就会掉帧。旧版React根本无法保证这一点。

---

Fiber是什么？

React团队花了两年多时间重写了调和算法，这就是Fiber。

Fiber = 新的调和架构

Fiber不仅仅是一个算法，它是一套全新的架构，包括：

1. Fiber节点------新的数据结构
2. Fiber树------新的组件树表示
3. 调度器（Scheduler）------时间切片和优先级调度
4. 双缓冲机制------current树和workInProgress树

Fiber节点长什么样？

每个React元素对应一个Fiber节点，它是一个链表结构：

function FiberNode(tag, pendingProps, key) {
  // 静态结构
  this.tag = tag;            // 组件类型（函数组件/类组件/原生元素等）
  this.key = key;
  this.type = type;          // 函数/类/标签名
  this.stateNode = stateNode; // 真实DOM节点或组件实例

  // Fiber树结构 ------ 链表！不是递归嵌套！
  this.return = parent;      // 父节点
  this.child = child;        // 第一个子节点
  this.sibling = sibling;    // 右边第一个兄弟节点
  this.index = index;        // 在兄弟中的位置

  // 工作单元
  this.pendingProps = pendingProps;  // 待处理的props
  this.memoizedProps = memoizedProps; // 上次渲染的props
  this.memoizedState = memoizedState; // 上次渲染的state
  this.updateQueue = updateQueue;     // 更新队列

  // 副作用
  this.effectTag = effectTag;  // 需要执行的操作（插入/更新/删除）
  this.nextEffect = nextEffect; // 下一个有副作用的节点

  // 双缓冲
  this.alternate = alternate;  // 指向另一棵树的对应节点
}

划重点：Fiber节点用链表（child/sibling/return）而不是嵌套对象来表示树结构。 这是Fiber能实现可中断调和的关键。

为什么链表这么重要？

递归嵌套的树，你没办法说"暂停一下，我等会儿再遍历"。因为调用栈里压着一堆函数帧，你没法在中间插入别的任务。

链表就不一样了。遍历链表可以用循环，循环的每一步都是独立的。你可以随时暂停，把当前节点记下来，等有空了再从当前节点继续。

// 伪代码：Fiber的工作循环
let currentFiber = rootFiber;

while (currentFiber) {
  // 处理当前Fiber节点
  processFiber(currentFiber);

  // 检查是否需要让出主线程
  if (shouldYield()) {
    // 暂停！保存当前进度，等下次调度
    break;
  }

  // 移动到下一个Fiber节点
  currentFiber = getNextFiber(currentFiber);
}

这就是Fiber的核心思路：把递归变成循环，把不可中断变成可中断。

---

双缓冲机制

Fiber架构维护了两棵树：

• current树：当前屏幕上显示的内容
• workInProgress树：正在构建的新树

为什么需要两棵树？

想象你在写文档，你不能一边修改原文一边把修改后的内容显示给读者看。你需要一份草稿，改好了再替换原文。

Fiber的双缓冲就是同样的道理：

1. 用户触发更新，React创建一棵新的workInProgress树
2. 在workInProgress树上进行调和（这个过程可以被中断）
3. 调和完成后，workInProgress树变成新的current树
4. 旧current树变成下一轮的workInProgress树

// 双缓冲切换
function commitRoot(root) {
  // workInProgress树完成，切换指针
  root.current = finishedWork;
  // 旧的current树自动变成新的workInProgress
}

alternate字段 就是连接两棵树的桥梁------每个Fiber节点的alternate指向另一棵树上对应的节点。

---

时间切片：让React"呼吸"

这是Fiber最酷的部分。

Scheduler------调度器

Fiber引入了一个独立的调度器（Scheduler），它负责决定什么时候执行Fiber工作，什么时候暂停让出主线程。

// 简化版调度逻辑
function workLoop() {
  while (currentFiber && !shouldYield()) {
    currentFiber = performUnitOfWork(currentFiber);
  }

  if (currentFiber) {
    // 还有工作没做完，请求下一次空闲时间
    requestIdleCallback(workLoop);
  } else {
    // 所有工作完成，提交更新
    commitRoot();
  }
}

function shouldYield() {
  // 检查当前帧是否还有剩余时间
  return getCurrentTime() >= deadline;
}

requestIdleCallback的局限

理论上，requestIdleCallback是浏览器提供的API，能在浏览器空闲时执行低优先级任务。但它有几个问题：

1. 兼容性差------Safari至今不支持
2. 执行频率低------浏览器可能一秒只调用一次
3. 时间不可控------空闲时间的长短完全由浏览器决定

所以React团队自己实现了一个更靠谱的调度器------Scheduler包 （现在独立为scheduler npm包）。

Scheduler的实现原理

Scheduler用MessageChannel来模拟requestIdleCallback：

const channel = new MessageChannel();
const port = channel.port2;

channel.port1.onmessage = () => {
  // 在这里执行Fiber工作
  const currentTime = getCurrentTime();
  deadline = currentTime + yieldInterval; // 通常5ms
  
  workLoop();
};

function scheduleWork() {
  // 通过MessageChannel触发下一次工作
  port.postMessage(null);
}

为什么用MessageChannel而不是setTimeout？

因为MessageChannel的优先级比setTimeout(0)高，但比用户交互事件低。这样既不会阻塞用户交互，又能尽快执行React的工作。

---

优先级调度：不是所有更新都一样急

Fiber另一个重要特性是优先级调度。不同的更新有不同的紧急程度：

优先级	场景	说明
同步（Sync）	用户输入、点击	必须立即处理
连续触发（Continuous）	拖拽、滚动	尽快处理，但可以合并
默认（Default）	数据请求返回	正常处理
空闲（Idle）	离屏渲染、预取	有空再处理

举个例子

你在输入框里打字，同时列表在加载新数据。Fiber会怎么处理？

1. 输入事件------高优先级，立即处理，确保输入框响应
2. 列表更新------低优先级，暂停，等输入处理完再继续

这就是为什么React 18里useTransition和useDeferredValue能让你的应用"感觉很流畅"------它们本质上就是在利用Fiber的优先级调度。

function SearchPage() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  function handleChange(e) {
    // 高优先级：输入框立即更新
    setQuery(e.target.value);
    
    // 低优先级：搜索结果可以稍后更新
    startTransition(() => {
      setResults(search(e.target.value));
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      {isPending && <Spinner />}
      <ResultList results={results} />
    </>
  );
}

---

工作阶段：Render和Commit

Fiber把一次更新分成两个阶段：

Render阶段（可中断）

这个阶段遍历Fiber树，计算差异，标记需要更新的节点。这个阶段是纯计算，不操作DOM，所以可以安全中断。

// Render阶段：对每个Fiber节点执行工作
function performUnitOfWork(fiber) {
  // 1. 处理当前节点
  beginWork(fiber);

  // 2. 遍历子节点
  if (fiber.child) {
    return fiber.child;
  }

  // 3. 没有子节点，完成当前节点
  completeUnitOfWork(fiber);

  // 4. 遍历兄弟节点
  if (fiber.sibling) {
    return fiber.sibling;
  }

  // 5. 回到父节点
  return fiber.return;
}

遍历顺序是这样的：A → B → D → E → C → F

    A
   / \
  B   C
 / \   \
D   E   F

Commit阶段（不可中断）

Render阶段完成后，React拿到了所有需要更新的节点（形成一个副作用链表）。Commit阶段一次性把这些更新应用到DOM上。

这个阶段不能中断，必须一口气完成。 因为如果你在操作DOM的过程中中断了，用户可能看到半成品界面。

function commitRoot() {
  // 遍历副作用链表，依次执行DOM操作
  let effect = root.nextEffect;
  while (effect) {
    commitWork(effect);
    effect = effect.nextEffect;
  }
}

---

踩坑记录

了解了Fiber原理之后，回头看我之前踩的那些坑，突然就都解释得通了。

坑1：componentWillMount里写副作用

旧版React里，componentWillMount会在Render阶段同步调用。Fiber架构下，Render阶段可能被中断和恢复，这意味着componentWillMount可能被调用多次。

这就是React 16.3之后废弃componentWillMount的原因。Render阶段的生命周期（willMount、willReceiveProps、willUpdate）都不安全。

正确做法：用componentDidMount和componentDidUpdate，它们在Commit阶段调用，只会执行一次。

坑2：大列表更新卡顿

如果你的列表有几千条数据，每次更新都触发整棵树的调和，即使用了key，计算量依然很大。

Fiber的优先级调度可以帮你，但需要你主动配合：

// ❌ 所有更新都是高优先级
setItems(newItems);

// ✅ 把大列表更新降级为低优先级
startTransition(() => {
  setItems(newItems);
});

坑3：并发模式下的竞态条件

React 18的并发特性让更新可以中断，这引入了新的问题------竞态条件。

// ❌ 可能拿到过时的数据
function SearchPage() {
  const [query, setQuery] = useState('');
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchData(query).then(setData);
  }, [query]);
}

// ✅ 使用清理函数取消过时请求
function SearchPage() {
  const [query, setQuery] = useState('');
  const [data, setData] = useState(null);

  useEffect(() => {
    let cancelled = false;
    fetchData(query).then(result => {
      if (!cancelled) setData(result);
    });
    return () => { cancelled = true; };
  }, [query]);
}

---

写在最后

React Fiber的本质就是一句话：把同步递归变成异步可中断的链式遍历。

听起来简单，但实现起来涉及数据结构、调度算法、优先级策略、双缓冲机制等一系列复杂的设计决策。React团队花了两年多才把这个东西做好，足以说明这个问题的难度。

理解Fiber之后，你会发现React 18的很多新特性都不再是"魔法"了：

• useTransition → 低优先级更新的语法糖
• useDeferredValue → 延迟更新的hook
• Suspense → 利用Fiber的暂停恢复能力
• Concurrent Mode → Fiber调度策略的全称

不瞒你说，我排查那个卡顿问题，最后就是用startTransition把大列表更新降级为低优先级搞定的。 加一行代码，主线程不再阻塞，用户操作丝滑如初。

如果这篇文章帮你理解了Fiber，点个赞👍。有什么疑问评论区聊～

---

React Fiber架构：https://github.com/acdlite/react-fiber-architecture
React 18新特性：https://react.dev/blog/2022/03/29/react-v18
Lin Clark - A Cartoon Intro to Fiber：https://www.youtube.com/watch?v=ZCuYPiUIONs