React Fiber 架构详解：为什么它能解决页面卡顿问题？

本文从问题与目标、核心数据结构、调度与中断、渲染阶段与提交阶段、优先级与 lanes、并发特性到常见误区与优化建议，全景式拆解 React Fiber，为何它能够显著降低交互卡顿并提升可响应性。

TL;DR

Fiber 将渲染过程切成可中断的小任务并在合适的时机继续执行
通过优先级与 lanes 模型，优先处理紧急交互，延迟非关键更新
渲染分两阶段：可打断的 render 与一次性提交的 commit，DOM 变更集中且短促
调度器以时间片与让渡机制避免长任务阻塞主线程，从而减少卡顿
并发特性如 useTransition、Suspense、选择性水合都建立在 Fiber 能力之上

卡顿的来源与架构目标

来源：长耗时任务阻塞事件处理与动画帧，渲染与计算无法及时让出主线程
目标：将更新拆解为细粒度单元，基于优先级可中断、可恢复且可重试的执行模型
兼容：保留类组件与函数组件的语义，支持 SSR、Hydration 与后续扩展

Fiber 的核心数据结构

每个 Fiber 对应一次渲染过程中的"工作单元"，以链表树结构组织:

ts 复制代码

type Lane = number

interface Fiber {
  tag: number
  key: null | string
  type: any
  stateNode: any
  return: Fiber | null
  child: Fiber | null
  sibling: Fiber | null
  alternate: Fiber | null
  lanes: Lane
  flags: number
  memoizedProps: any
  memoizedState: any
  updateQueue: any
}

child 与 sibling：链式树遍历更适合增量执行
alternate：当前树与待提交的工作树双缓冲切换
lanes 与 flags：控制优先级与记录副作用

两阶段模型：render 与 commit

render 阶段：构建工作树、计算变更列表，允许中断与恢复
commit 阶段：一次性将变更应用到 DOM 与副作用，尽量短小
好处：长计算不阻塞浏览器事件与动画，提交阶段集中且可控

调度与时间片：避免长任务阻塞

以切片执行的工作循环进行遍历，接近以下伪代码:

ts 复制代码

let workInProgress: Fiber | null = null

function shouldYield() {
  return performance.now() >= deadline
}

function workLoop() {
  while (workInProgress && !shouldYield()) {
    workInProgress = performUnitOfWork(workInProgress)
  }
  if (workInProgress) scheduleNextTick(workLoop)
}

通过 shouldYield 在每个单元之间检查是否需要让渡控制权
调度器依据任务的 lanes 与浏览器空闲时间安排后续执行

优先级与 lanes：谁更重要先做谁

lanes 是位掩码表示的多优先级融合模型
高优先级任务包含输入响应与选择性水合，低优先级用于非关键渲染
多任务可归并到 lanes，调度器据此选择下一个单元

为什么能缓解卡顿

将不可打断的同步树遍历改造为可暂停的单元工作
遇到输入事件或动画帧时及时让渡，保障主线程响应
区分紧急与非紧急更新，减少无关变更抢占时间片
commit 阶段将 DOM 变更批量一次性应用，缩短布局与绘制冲击

并发特性与 Fiber 的关系

useTransition 与 startTransition：将更新标记为非紧急，排在紧急交互之后
Suspense：在资源未就绪时挂起某些子树，避免阻塞页面可交互区域
选择性水合：SSR 下优先水合用户交互路径上的组件
useDeferredValue：推迟昂贵的派生计算以保证输入响应速度

工作循环与单元执行

ts 复制代码

function performUnitOfWork(fiber: Fiber): Fiber | null {
  beginWork(fiber)
  if (fiber.child) return fiber.child
  let node: Fiber | null = fiber
  while (node) {
    completeWork(node)
    if (node.sibling) return node.sibling
    node = node.return
  }
  return null
}

beginWork 生成子节点与比较 props
completeWork 构建副作用列表与准备提交信息
在每个单元之间检查让渡条件，实现可中断的深度优先遍历

典型场景与实践

大列表渲染：结合虚拟滚动与并发更新，输入滚动时保持流畅
复杂表单输入：将非关键重排与昂贵计算置于过渡更新
数据获取与占位：用 Suspense 显示骨架屏并保持交互域可用
SSR 水合：优先水合导航与交互区域，其余延后进行

常见误区

认为 Fiber 自动优化所有卡顿。若 render 执行中包含长耗时同步逻辑，仍会占用时间片
在 commit 阶段做重计算或强制同步布局会导致帧率下降
不当的频繁状态变更会增加任务竞争，需进行归并与降频
忽视 keys 与结构稳定性会增加无效重建

性能建议

用 useTransition 或批处理分离紧急与非紧急更新
将昂贵计算移动到 memo 化或后台任务，减少 render 成本
控制 commit 的 DOM 变更数量与粒度，避免反复测量布局
优化列表与表格，采用虚拟化与分块渲染
使用 Profiler 与 Performance 工具定位长任务与热点组件

总结

Fiber 的核心价值是以可中断、可恢复的增量执行模型替代不可分割的同步渲染。它结合优先级与时间片调度，将紧急交互放在首位，并通过分阶段提交降低 DOM 变更的集中冲击。理解 Fiber 的数据结构、工作循环与并发特性，有助于在真实项目中系统性地治理卡顿问题并提升整体可响应性。

进阶解析：优先级体系与 lanes 细节

React 18 将早期的 Scheduler 优先级（Immediate/UserBlocking/Normal/Low/Idle）抽象为 lanes；一个更新可以占用多个 lanes
lanes 使用位掩码，便于合并与比较；渲染时选择最高优先级的 lane 作为下一帧的工作目标
离散事件（点击、输入）通常赋予高优先级；连续事件（滚动、鼠标移动）优先级较低并可被打断
协调策略：
- 合并同类型低优更新，减少重复工作
- 当高优更新到来时，打断当前 render，保存现场并优先处理高优
- 超时控制避免低优任务长期饥饿

双缓冲与副作用标记

双缓冲：current 指向已提交的树；workInProgress 是正在构建的工作树，二者通过 alternate 互为镜像
副作用标记（flags）记录节点的变更类型（Placement/Update/Deletion 等）
render 阶段构建副作用链表，commit 阶段按序遍历执行，确保 DOM 变更集中完成

被打断的渲染如何恢复

渲染在单元边界处可暂停，恢复时从上次的 workInProgress 继续
bailout：若某子树 props/state 未变化或 shouldComponentUpdate/React.memo 判定无需更新，则跳过子树计算
重试与挂起：配合 Suspense 对未就绪数据的子树进行挂起，数据可用后再重试该子树

并发渲染与用户体验

并发渲染不是并行执行，而是允许在同一线程的不同时间片中交替推进多个树的渲染
用户可见区域优先：借助优先级与选择性水合，优先渲染交互路径上的组件，降低首屏交互延迟
资源阻塞治理：Suspense 将依赖资源的子树挂起，用占位/骨架提升感知速度，避免整页卡住

调度器内部要点

时间片长度根据环境动态调整，浏览器与 Node 环境采用不同的定时/消息通道策略
在支持的浏览器中可利用 navigator.scheduling.isInputPending() 判断是否存在待处理的输入事件，从而更积极地让渡
微任务与宏任务配合，确保任务队列与渲染队列之间的公平性，避免某一方长时间独占

代码示例：用过渡更新缓解输入卡顿

tsx 复制代码

import { useMemo, useTransition, useState } from 'react'

export default function FilterList({ items }: { items: string[] }) {
  const [query, setQuery] = useState('')
  const [isPending, startTransition] = useTransition()

  const filtered = useMemo(() => {
    const q = query.toLowerCase()
    return items.filter(i => i.toLowerCase().includes(q))
  }, [items, query])

  return (
    <div>
      <input
        value={query}
        onChange={e => {
          const v = e.target.value
          startTransition(() => setQuery(v))
        }}
        placeholder="输入过滤关键词"
      />
      {isPending && <span>计算中...</span>}
      <ul>
        {filtered.map(i => <li key={i}>{i}</li>)}
      </ul>
    </div>
  )
}

将 setQuery 放入 startTransition，把过滤计算标记为非紧急更新，输入响应优先不卡顿

代码示例：Suspense 与数据就绪的挂起

tsx 复制代码

function UserCard() {
  const user = useUserResource() // 内部抛出 Promise，待数据就绪再继续渲染
  return <div>{user.name}</div>
}

export default function Page() {
  return (
    <Suspense fallback={<Skeleton />}>
      <UserCard />
    </Suspense>
  )
}

未就绪时渲染 fallback，就绪后恢复渲染子树；配合 Fiber 的可中断模型提升感知速度

SSR 与选择性水合

React 18 的流式 SSR 将 HTML 分块输出，客户端根据用户交互路径优先水合必要组件
选择性水合避免一次性水合整棵树导致的主线程拥塞，优先保证可点击/可输入区域

诊断与优化清单

渲染开销：
- 使用 Profiler 捕获长耗时组件
- 用 memo/useMemo/useCallback 控制派生与重建
提交阶段：
- 合并 DOM 变更，避免在 commit 中进行昂贵计算或强制布局
- 减少同步测量与多次读写交错导致的布局抖动
任务竞争：
- 将非关键更新放入 useTransition 或批处理
- 对频繁状态用节流/防抖或批量归并
结构稳定性：
- 正确使用 key，减少无谓 diff 与重排
- 列表/表格采用虚拟化与分块渲染

常见反模式与替代方案

在渲染或副作用中执行大循环或密集计算，可改为后台 Worker 或增量计算
在 useEffect 中频繁、同步地读取布局并写入样式，改为批量读后批量写或转移到动画帧
不区分紧急/非紧急更新导致输入抖动，使用 startTransition 分离

小结与实践建议

评估场景：是否存在长列表、复杂派生、频繁交互或数据阻塞
策略组合：优先级划分 + 并发渲染 + 占位与水合 + 结构优化
工具链：Profiler、Performance、Lighthouse 联合定位瓶颈，结合日志采样观察真实终端表现