如果你在前端圈混过一段时间大概率躲不开这两个名字React 和 Vue。而不管你是准备面试、做技术选型还是单纯想把基础打牢“渲染流程”都是绕不开的深水区。不少人在面试时被问到 “React 和 Vue3 的渲染流程有什么区别”第一反应是“React 用虚拟DOMVue3 也用虚拟DOM好像差不多”。但真要落实到源码层面、性能表现和优化手段上这两者走的其实是完全不同的两条路。这篇笔记我打算把两边从“数据变了”到“界面更新”的完整链路拆开揉碎放在一起做一次横向对比。不吹不黑只讲机制和取舍。适合准备 React 或 Vue3 面试的开发者也适合那些想在项目里做出更合理技术选型的朋友。看完之后你至少能回答清楚为什么 Vue3 的更新可以做到组件级精细为什么 React 需要 Fiber 这种“打断重来”的机制以及两者在优化思路上到底谁更“聪明”。1. 渲染流程的整体设计思路拆解1.1 React 的“一切皆组件”与从根开始的协调React 的渲染流程核心逻辑可以概括为一句话从根组件开始递归地把整个组件树走一遍生成新的虚拟 DOM 树然后和旧的虚拟 DOM 树做对比找出差异最后把差异更新到真实 DOM 上。这个过程在 React 中被称为“协调”Reconciliation。从 React 16 开始协调过程被重构成了 Fiber 架构但整体的设计思路没有变——它依然是“自顶向下、递归遍历、整树对比”。这意味着什么呢意味着在 React 的世界里如果你有一个大组件树某个叶子节点上的状态变了React 并不会“精准地”只更新那一个叶子节点。它会从根节点开始把整棵树重新遍历一遍重新执行每个函数组件的代码或者在类组件里执行 render 方法生成新的虚拟 DOM然后再去做 diff。虽然 diff 阶段会跳过那些没有变化的节点但“重新执行组件函数”这一步是不管你有没有变化都会发生的。这也是为什么 React 的性能优化总是围绕 “避免不必要的重新渲染” 来展开——因为默认情况下父组件更新子组件也会跟着重新执行。1.2 Vue3 的“响应式驱动”与组件级更新Vue3 的渲染流程核心逻辑则是另一套思路数据驱动视图数据变了精准地找到依赖这个数据的组件只重新渲染那一个组件。Vue3 引入了基于 Proxy 的响应式系统组件在渲染过程中会“收集依赖”——也就是说这个组件用了哪些响应式数据都会被记录下来。当某个数据发生变化时响应式系统会精确地通知到依赖它的组件触发该组件的重新渲染。这个设计带来的最直观体验是Vue3 的组件更新是“自下而上”的而且是“按需”的。父组件里的响应式数据变了父组件重新渲染子组件如果没有依赖这个数据那子组件完全可以不跟着动。这种精细度是 Vue 天然自带的不需要开发者额外做任何优化。所以在整体思路上两者就有本质区别React 是“状态变了从根重新开始靠 diff 找差异”Vue3 是“数据变了精准定位受影响的组件最小化更新范围”。一个偏“运行时暴力对比”一个偏“编译时 运行时结合”。这两种思路没有绝对的谁好谁坏但它们的优缺点在后续的更新机制、优化成本和开发体验上会有非常明显的差异。2. React 渲染流程的核心机制深挖注意这一节我们聚焦 React 的 Fiber 架构因为这是 React 渲染流程的核心。看完这一节你就能理解为什么 React 的渲染过程“可以被打断”。2.1 从虚拟 DOM 到 Fiber 架构React 的“时间分片”思路先说一个 React 面临的老大难问题JavaScript 是单线程的一旦 React 开始递归遍历组件树生成虚拟 DOM这个过程是不能停下来的。如果组件树很大这个同步的递归过程会霸占主线程导致用户点击、输入这些交互事件得不到响应——也就是所谓的“掉帧”“卡顿”。React 团队的解法是 Fiber 架构。Fiber 的本质是一个具有链表结构的节点对象每个组件都会对应一个 Fiber 节点。这些 Fiber 节点通过child、sibling、return这三个指针串联成一棵树替代了原来的递归调用栈。有了这个链表结构遍历组件树的过程就从一个“递归调用、不可中断的函数”变成了“迭代循环、可以暂停恢复的工作单元”。React 在每处理完一个 Fiber 节点后都会检查当前主线程是否还有空闲时间。如果没有就把当前的状态保存下来把控制权交还给浏览器让它先去处理用户的交互、动画等任务等浏览器有空了再回来接着干。这就是 React 的“时间分片”Time Slicing思路。它解决的问题是渲染大组件树时不再阻塞主线程让页面始终保持可交互状态。2.2 render 阶段和 commit 阶段React 的渲染流程被明确分成了两个阶段render 阶段也叫协调阶段和 commit 阶段提交阶段。render 阶段做的事情是遍历 Fiber 树执行函数组件的代码或者类组件的 render 方法通过beginWork和completeWork这两个核心函数生成新的子 Fiber 节点并在这个过程中进行 diff 操作标记录需要更新的节点。这个阶段可以被打断被打断后可以从上次中断的节点继续往下走。这也是他被称为“可中断阶段”的原因。commit 阶段做的事情则是把 render 阶段标记好的更新一次性同步地应用到真实 DOM 上。这个阶段不可被打断必须一气呵成——因为如果提交到一半被打断用户看到的界面就会处于一个“半更新”的状态这显然是无法接受的。理解这两个阶段的区别特别重要。我在面试别人的时候经常问一个问题“React 的渲染过程可以被打断吗”答案不是简单的“可以”或“不可以”而是“协调过程可以被打断提交过程不能被打断。”2.3 双缓存机制与 workInProgress 树React 内部维护了两棵 Fiber 树一棵是当前屏幕上显示的内容对应的树叫current树另一棵是在内存中正在构建的树叫workInProgress树。每次更新时React 都会基于current树创建一棵新的workInProgress树在这棵新树上做各种计算和标记。当 render 阶段全部完成workInProgress树构建完整之后在 commit 阶段React 会把这个两棵树的current指针直接切换让workInProgress树变成新的current树完成“双缓存”的交换。这样做的好处有两个第一在替换完成之前用户看到的始终是旧的树不会出现“闪一下半成品界面”的情况第二下次更新时可以直接复用上一次的workInProgress树作为基础省去重复创建的开销。3. Vue3 渲染流程的核心机制拆解3.1 挂载阶段的完整链路从模板到真实 DOMVue3 的渲染流程我习惯分成两个大阶段来看一个是首次挂载mount一个是更新update。首次挂载的链路是这样的先通过编译器把 template 模板编译成 render 函数这一步如果使用 vue-loader 或 vite 插件在构建阶段就完成了如果在浏览器里运行则会在运行时编译。然后调用 render 函数生成虚拟 DOM 树。接着进入 patch打补丁阶段遍历虚拟 DOM 树创建对应的真实 DOM 节点递归挂载子节点最后把整棵 DOM 树插入到容器中。在这个过程中Vue3 会为每个组件实例初始化响应式系统也就是对组件中用到的 data、props、computed 等做 Proxy 代理。这些响应式数据在 render 函数执行期间被访问时就会触发track依赖收集操作建立“数据 → 组件/副作用”的映射关系。这样后续只要这些数据发生变化就能立刻找到需要更新的组件。挂载完成后Vue3 还会建立一些对应的更新队列和调度器。数据变化时不会立刻同步执行更新而是把需要更新的组件放进一个队列里在下一个微任务microtask中统一执行。这种异步批量更新机制保证了即使你在一个事件里连续改了多次数据组件也只会被重新渲染一次避免了无意义的重复开销。3.2 编译时优化静态提升与动态节点标记Vue3 在编译模板时做了很多针对性的优化这是它和 React 拉开差距的一个关键点。第一是静态提升。编译器在编译模板时会识别出哪些节点是纯静态的不依赖任何响应式数据把这些节点提升到 render 函数外部只在首次渲染时创建一次之后更新时直接复用不需要再次创建和 diff。第二是动态节点标记patch flags。对于动态节点编译器会标记出它具体是动态的什么属性——是动态的 class、动态的 style还是动态的文本内容。在更新阶段Vue3 可以根据这些标记只对比动态的部分跳过静态部分的对比。这相当于在 diff 阶段开了一个“精确制导”的外挂把对比的范围大幅缩小。第三是Block Tree区块树的概念。Vue3 会基于模板的结构把节点划分成一个个 Block只在 Block 内追踪动态节点。配合前面说的 patch flagsVue3 在做 diff 时可以直接跳过整个没有动态内容的 Block大大减少了对比工作量。3.3 更新阶段的“最小化更新”是怎么做到的当响应式数据变化时Vue3 的trigger会触发依赖这个数据的组件更新。但这里的“组件更新”并不是直接操作真实 DOM而是先执行组件对应的更新函数。这个更新函数会重新执行组件的 render 函数生成新的虚拟 DOM 树然后和旧的虚拟 DOM 树做 patch。由于编译阶段的优化Vue3 在做 patch 时能迅速定位到真正发生变化的节点和属性把更新操作压缩到最小范围。而且组件更新时只会更新自己内部的模板对于子组件如果子组件没有依赖变化的响应式数据且 props 也没有发生变化Vue3 会直接跳过该子组件的重新渲染。这种“组件级粒度的跳过”是 Vue3 在运行时层面天然具备的优化不需要开发者手动使用什么 API 去干预。4. 核心差异对照React 和 Vue3 谁更“聪明”4.1 运行时 vs 编译时两条路线的博弈React 的虚拟 DOM 和 diff 完全发生在运行时JSX 只是一个语法糖编译后只是一堆React.createElement调用的嵌套没有任何额外的编译信息可供优化。这就决定了 React 只能在运行时“硬对比”整棵虚拟 DOM 树靠通用的 diff 算法去找到差异。Vue3 则不一样它有一个非常强大的编译器。模板在编译阶段就已经被分析得一清二楚哪里是静态的、哪里是动态的、动态的是属性还是文本。这些信息在运行时被用来“精确制导”让更新过程少做很多无用功。但是这里要补充一点Vue3 如果你完全使用 JSX / h 函数来写组件那编译期的这些优化大部分就用不上了性能表现会退化为接近运行时对比的水平。这也是为什么 Vue3 官方依然推荐优先使用 SFC单文件组件模板写法而不是 JSX。4.2 调度机制与更新粒度的区别我在前面的章节已经分别说过了React 是“从根组件开始整树递归对比”Vue3 是“响应式驱动、组件级精准更新”。这里把它们的优缺点摊开来看维度ReactVue3更新起点通常从根组件开始或触发更新的那个组件向上遍历整棵子树精确到依赖了变化数据的那个组件是否可中断协调阶段可中断Fiber 时间切片不可中断但更新任务会异步批量入队diff 范围需要对比两个虚拟 DOM 树依赖编译期标记可以跳过大量静态节点默认优化成本需要开发者主动使用 memo、useMemo、React.memo 等组件级更新和编译优化是内建的大部分场景默认就是够优的一个特别值得注意的点是React 的更新触发机制在默认情况下“波及面”更大但它采用了“并发渲染”Concurrent Rendering来保证即便更新任务很重也不会阻塞用户交互。Vue3 则选择了“更少的工作量”这个策略——尽量让每次更新要处理的节点数量变少从源头减少性能压力。一个是“打不过就分片”一个是“料敌机先精准打击”。4.3 性能优化的手段memo 与 shallowRef在 React 里最常用的性能优化手段是React.memo、useMemo和useCallback。它们的核心目的只有一个控制组件的重新渲染次数。React.memo对组件的 props 做浅比较props 没变就跳过渲染useMemo缓存计算结果useCallback缓存函数引用都是为了配合React.memo或者 effect 的依赖对比。而在 Vue3 里组件更新本身是精确到组件级的所以你不太需要担心“子组件被父组件白白重渲染”的问题。Vue3 里更常见的优化是对于复杂计算用computed做缓存对于需要主动跳过更新的场景用shallowRef或shallowReactive来减少深层响应式追踪的开销。这里面的思维差异挺有意思的React 的优化是“堵”堵住不必要的重新渲染Vue3 的优化是“疏”让该更新的更新、不该更新的天然不更新。5. 高频面试题与业务场景选型实战5.1 面试必答题两个框架渲染流程的核心差异怎么答面试中问到两者区别建议按照“整体思路 → 更新起点 → 调度机制 → 编译优化 → 优化手段”这个顺序来答React 走的是运行时协调的路线JSX 编译后不携带额外优化信息。状态变化后默认从根组件开始递归遍历 Fiber 树生成新的虚拟 DOM做 diff 后提交更新。为了让大组件树更新不阻塞主线程React 引入了 Fiber 架构并支持时间切片让协调过程可中断但提交阶段不可中断。React 的默认更新粒度是“整棵子树”所以需要开发者用 memo 等 API 手动控制渲染范围。Vue3 走的是编译时 运行时结合的路线。模板编译阶段会做静态提升、动态节点标记等优化运行时通过响应式系统精确追踪依赖。数据变化后直接触发依赖该数据的组件更新组件内部 diff 时也能借助编译信息跳过大量静态节点。Vue3 的默认更新粒度就是组件级的所以大部分场景不需要开发者手动优化。这样回答的好处是从原理出发而不是背结论面试官追问任何细节你都能接得住。5.2 业务场景下如何选择不是“谁好”而是“谁更合适”技术选型从来不是“谁厉害选谁”而是“谁更匹配你的业务情况”。根据我这些年在不同项目里的体会分几类典型场景来说如果你的项目是大规模后台管理系统、复杂数据可视化大屏组件树层级很深、页面数量多Vue3 的组件级精准更新和编译优化会明显省心。尤其是表格、图表这类高频数据刷新场景Vue3 默认不需要任何额外处理就能保持不错的性能。如果你的项目是一个重型前端应用比如在线文档、协同编辑工具组件状态交互极其复杂团队又有较强的工程化能力React 的生态和 Fiber 架构的并发能力可能更合适。React 的“从头协调”模式配合良好的 memo 规划能应对非常复杂的交互逻辑。而且 React 生态里的周边库、可复用方案在很多领域依然是天花板级的存在。如果你是个人开发者或者小团队追求开发效率和较低的学习曲线Vue3 的单文件组件 Composition API 内置的响应式系统可以说相当舒服。模板写法对后端人员也非常友好。反过来如果你的团队全是 React 老手强行换 Vue 反而不是好选择——团队熟悉度本身就是最大的变量。5.3 我踩过的坑和一些建议最后说一下我实际用这两个框架时总结的一些经验。React 里我踩过最大的坑是一开始没注意函数引用的稳定性。父组件重新渲染后每次传给子组件的函数都是新引用子组件即使包了React.memo也照样重新渲染这就是useCallback存在的意义。但这种依赖手动优化的模式很容易出现“忘了包 memo”或者“useCallback 依赖写错”的情况优化起来费神费脑。Vue3 这边最大的坑反而是“太容易了”。因为响应式系统自动追踪依赖你不小心在模板里写了一个开销很大的表达式它可能每次渲染都会重新执行。Vue3 的模板并不像 React 那样有 render 函数里可以写的完整 JS 逻辑所以一些复杂计算还是要放到computed里做缓存避免每次渲染都重复计算。如果你是在做技术选型我的建议是先用一两周时间把两个框架的官方文档和核心原理都过一遍写几个小 demo 感受一下差异。不要只盯着“性能数据”选型而是要关注“团队能否驾驭”“生态是否匹配”“后续维护是否顺畅”。框架本身没有银弹真正决定项目上限的还得是团队的功底和项目的领域逻辑。