前端圈子里有一个很有意思的现象你去面技术岗大概率会被问到一个组合包——Vue 和 React 的优缺点是什么虚拟 DOM 到底解决了什么问题以及什么时候你会“拥抱原生 DOM”这个组合包我听过无数次也回答过无数次后来才琢磨明白它其实是一条完整的认知链先看框架选型再看框架底层最后看浏览器本身。把这三点串起来才算真的把前端这层窗户纸捅破。这篇文章我想用最直接的方式把 Vue、React、虚拟 DOM、原生 DOM 这几个东西拆开揉碎讲清楚。不管是正在准备面试、做技术选型还是刚入行想搞明白框架背后发生了什么都应该能从中拿走你想要的东西。我尽量不堆概念只讲我真实接触过的场景和踩过的坑。1. 先搞清楚这三个问题为什么总被绑在一起问1.1 一条从选型到底层的认知链很多同学在准备面试时会分别背“Vue 的优点”“React 的优点”“虚拟 DOM 的原理”但一到追问环节就露馅因为这三个话题本来就是环环相扣的。面试官真正想确认的是你究竟是“会调 API 的人”还是“理解原理的人”。你可以熟练写.map渲染列表但如果连“为什么列表要加 key”都答不到点子上那就说明你还没有真正理解虚拟 DOM 的 diff 机制也更谈不上理解框架的设计取舍。我之前参与过不少前端终面也做过一些团队的选型评审经验是能清晰说出 Vue 的响应式依赖追踪和 React 的重新渲染流程差异的人往往写代码时对性能问题更敏感。反而那种“Vue 好用”“React 灵活”挂在嘴边的人遇到线上卡顿只能干瞪眼。技术选型不是投票选偶像背后是一整套关于状态、渲染、更新的取舍逻辑。1.2 一切争议的源头数据变化后UI 怎么跟着变浏览器厂商给了我们一套非常底层的 DOM API你可以document.querySelector找到节点也可以element.textContent改内容。这套 API 很强大但它有一个致命问题——你自己要记住“哪块数据对应哪个节点”然后手动去更新它。一个页面有几十个状态和几百个节点时这件事会变成灾难。而 Vue 和 React 要做的是同一件事让你只描述“UI 长什么样”框架来负责“数据变了 UI 自动更新”。区别在于它俩用了两条完全不同的路线。Vue 用响应式系统数据一变立刻知道哪些地方要更新React 用不可变数据和渲染函数每次状态变化都把整个组件重新渲染一遍再用虚拟 DOM 找出差异。再加上浏览器原生 DOM 这个最底层的“手动挡”三方一对比答案自然就浮出水面了。2. Vue 和 React 优缺点拆解一张表看懂设计路线2.1 响应式 vs 重渲染两条路线的世界观差异Vue 的核心武器是响应式系统。早期版本用Object.defineProperty现在用Proxy本质都是在数据被读取时收集依赖、在被修改时触发更新。所以 Vue 非常“聪明”数据变了它精确知道哪些组件和渲染函数需要重跑而且粒度可以控制到组件内部的小块。用起来的感觉是你只管改数据页面像被施了魔法一样自动更新。React 走了另一条路。React 无法自动感知数据的变化它的哲学是“状态是不可变的你创建一个新状态然后整个组件重新渲染”。所以 React 遇到状态变更会重新执行你的组件函数生成一棵新的虚拟 DOM 树再拿去和旧树对比。从实现原理上React 做的“脏活”更多于是它提供了各种缓存和剪枝手段memo、useMemo、useCallback都是为了减少不必要的重新渲染。这样带来的优缺点非常明显Vue 上手直观、性能下限高你按推荐方式写就不用太担心渲染浪费React 则把主动权完全交给你写得好可以非常精细写不好会到处console.log发现组件莫名重渲染。我见过不少团队在 React 项目里抱怨“怎么改一个状态整个页面都闪”本质就是没控制好渲染范围。2.2 模板语法 vs JSX表达力与约束的取舍Vue 默认走模板语法比如v-if、v-for非常接近普通的 HTML 写法非前端背景的人也能快速看懂。模板的代价是它是一套 DSL领域特定语言表达能力比 JS 弱一些复杂的逻辑分支得靠计算属性或方法兜着。不过 Vue 也支持 JSX关键看团队怎么选。React 则是彻头彻尾的“JS 第一”JSX 就是为了让你能用写 HTML 的方式写 JS但它本质上是函数调用和表达式。这意味着你可以直接在 JSX 里写{arr.map(...)}、{condition Component /}所有逻辑都是 JS灵活度极高。代价就是“自由度过高”团队里如果没有约定很容易写出思路放飞、难以维护的组件。我个人的真实体会是如果团队里初级开发多、业务以中后台表单和内容展示为主Vue 模板能天然约束住很多坏写法如果要做复杂交互组件、需要高度抽象复用React 的 JSX 会顺手很多。这不是谁强谁弱的问题是“约束 vs 自由”在具体团队里的平衡问题。2.3 生态、上手曲线与长期维护的隐性成本Vue 一直给人“渐进式框架”的印象官方把路由、状态管理、构建工具全部收编成一套全家桶你照着官方文档走基本不会走偏。这让“从零搭一个项目”变得非常顺畅国内很多团队第一选择就是 Vue学习资料和中文文档也友好。React 则把“碎片化”发扬光大路由归路由、状态管理归状态管理、数据请求归数据请求全部由社区提供方案你可以自由组合。好处是你会接触到更多模式学到很多超越框架本身的工程化思想坏处是新接触的人非常容易迷茫光选一个状态管理库都能纠结好几天而且不同 React 项目之间代码风格可能差距巨大。从长期维护角度Vue 的官方约束能降低团队沟通成本React 则需要团队自己建立规范。我参与过的项目里Vue 项目到后期其实更容易接手因为写法相对统一React 项目如果早期没有做好组件层级和状态归属的规范后期就像在一座违章建筑里加隔断每改一处都胆战心惊。2.4 一张对比表和我常用的选型判断流程维度VueReact学习曲线平缓模板直观较陡需要适应 JSX 和函数式思维渲染机制响应式依赖追踪精准更新重新执行渲染函数 diff 协调灵活性官方约束较强模板化高度灵活JS 表达力全开生态官方全家桶路径统一社区生态庞大组合自由调试devtools 直观依赖关系清晰渲染逻辑复杂时需要更多 profiling 手段团队协作写法统一规范成本低高度依赖团队自律和代码评审典型业务中后台、C 端稳定页面复杂交互、跨端渲染、大规模应用我自己的选型流程很简单先列业务形态再列团队画像。如果你要在一个月内交付一个管理后台团队以二三年经验同学为主Vue 是稳妥选择如果你要做类似在线编辑器、数据可视化搭建平台这种高度动态的 SPA团队里有几个能控制渲染性能的同学React 的优势会很大。选框架不是比谁更好是比谁更匹配当下的约束条件。3. 虚拟 DOM它解决的本质问题是“协调”而不是“快”3.1 没有虚拟 DOM 的年代手动操作页面有多容易出错在 Vue 和 React 还没成为主流的时代最常见的做法是把数据渲染到 HTML 模板里然后监听用户操作再用innerHTML重建一块区域或者用 jQuery 选择器精确改几个元素。听起来也不复杂但项目一大就原形毕露——你永远在担心“我改了这个状态别的地方的显示还同步吗”。举一个很典型的例子一个表格行内有一个复选框复选框的状态又联动行样式和合计数值。用户勾一下你要手动更新复选框、行 class、合计文字可能还有另一个面板里的统计数据。只要有一步忘了UI 和数据就不同步了。这种“命令式同步”非常脆弱而且性能也堪忧因为很多人图省事直接innerHTML重建整个表格哪怕只改了一行的状态。所以虚拟 DOM 真正的意义首先不在快而在于讓开发模式从“手动命令式”变成了“声明式”。你只管给框架一个目标状态框架负责从当前状态迁到目标状态。这个“迁移过程”的调度器就是虚拟 DOM 和 diff 算法。3.2 虚拟 DOM 到底在干什么从 JS 对象到真实节点所谓虚拟 DOM本质上是一个用来描述真实 DOM 结构的普通 JS 对象大概长这样// 一个最简单的 vnode 结构 const vnode { tag: div, props: { id: app, className: container }, children: [ { tag: span, props: {}, children: hello }, { tag: p, props: {}, children: world } ] }这个 JS 对象又轻又便宜创建一万个也不会真的去触碰浏览器渲染引擎。当你改数据时框架会生成一棵新的 vnode 树然后用旧的 vnode 树和新的 vnode 树做一次对比diff找出哪些节点变了最后只把变化的部分提交给真实 DOM。整个过程就是经典的“渲染管线”声明式描述 - 生成 vnode - diff - patch打补丁- 更新真实 DOM。这个设计的精妙之处在于它把“计算差异”和“修改 DOM”这两个动作分离了。计算差异是纯 JS 行为很快修改真实 DOM 才是昂贵操作尽量减少它就是虚拟 DOM 的价值所在。3.3 diff 算法的核心思路同层比较、key 与更新的最小化虚拟 DOM 对比绝对不是把旧树和新树做一个全量递归比对那样复杂度会到 O(n^3)。框架们普遍采用一个朴素的启发式策略同层比较。只对比同一层级的节点不跨层级移动。这样复杂度降到了 O(n)代价是放弃了一些理论上最优的移动方案但实际业务中跨层移动节点的场景非常少这个权衡非常划算。同层对比的基础上列表就变得很敏感了。你渲染一个数组如果没加 key框架只能靠位置一一对比一旦数组中间插入一项后面所有节点都会被当成“变了”全部重新创建性能白白损失。加了 key 之后框架就能识别出“这个节点只是换了位置”可以复用 DOM 元素。这就是 key 的本质作用帮助 diff 算法识别节点的身份。关于 key我见过最常见的坑是用 index。用索引做 key等于告诉框架“第一个节点永远是第一个节点”。一旦列表发生插入、删除或排序索引随之改变框架会误判身份导致组件状态错乱比如复选框勾选状态串行、输入框里的内容对错位。正确做法是使用数据中稳定且唯一的业务 ID这是一个影响用户体验和正确性的细节真的很重要。3.4 虚拟 DOM 的隐形代价它不是性能银弹很多人都背过一句话“虚拟 DOM 比操作真实 DOM 快”严格来说这是不准确的。虚拟 DOM 引入了额外的内存开销维护 vnode 树也引入了额外的计算开销每次更新都要 diff。真实 DOM 更新已经很快真正慢的是浏览器收到 DOM 变更后触发的布局、绘制、合成等后续渲染流程。那虚拟 DOM 的优势到底在哪它的优势是“把多次零散的 DOM 操作合并成一次精确的补丁”比如一次事件里改了十个地方的数据框架可以在一个微任务周期内把它们合并成一轮 diff 和一次 patch避免浏览器被反复打扰。同时虚拟 DOM 把渲染机制抽象成了 JS 对象这为跨端渲染提供了基础——同一套代码可以渲染到浏览器 DOM也可以渲染到小程序或原生移动端。所以虚拟 DOM 是个“效率调度器”它优化的不是单次 DOM 操作而是多次状态变更下的整体渲染路径。你要是把它当成“一定快”在高频细粒度更新的场景里就会失望。这也是为什么现在的框架都在做编译时优化Vue 的静态提升、React 的 memo本质上是想在虚拟 DOM 之上再加一层“能省则省”的保险。4. 拥抱原生 DOM在框架之外重新拿回浏览器的手感4.1 什么时候虚拟 DOM 会拖后腿既然虚拟 DOM 本质是“先算差异再更新”那它最难受的场景就是状态更新频率极高、每次更新的 DOM 范围又很明确。比如实时刷新的大屏监控、拖动条连续变化、WebGL 或 Canvas 上的大量图形这些场景里 diff 带来的计算开销反而成了瓶颈。我印象很深刻的一次是做个“实时刷新的列表”每秒钟后端推送几十条数据列表顶部要不停插入新消息。用框架写每来一条数据都要经历一次组件更新和 vnode diff列表越长越吃力。后来改成原生 DOM 往容器顶部插入节点开销直接从“整棵列表 diff”降到了“添加几个节点”体感立刻顺畅了。这让我意识到框架再好用也不等于所有场景都该用它。4.2 原生 DOM 的三种高效打开方式既然要拥抱原生那就要拥抱得专业。首先操作原生 DOM 并不是简单地用querySelector到处抓节点而是要遵循浏览器的脾气。第一招是批量操作。频繁往 DOM 里添加节点时不要一个个appendChild而是先挂到DocumentFragment上再一次性地挂进页面。这样做可以让浏览器只做一次渲染任务。const fragment document.createDocumentFragment(); for (let i 0; i 1000; i) { const li document.createElement(li); li.textContent 第 ${i} 项; fragment.appendChild(li); } list.appendChild(fragment);第二招是避免强制同步布局。如果你在一个循环里“改样式再读布局属性”比如先el.style.width 100px再立刻el.offsetWidth浏览器会被迫提前计算布局也就是所谓的“强制回流”。正确做法是先把要改的样式统一写到 DOM 上读布局信息的操作集中放到下一帧或者直接用requestAnimationFrame调度。第三招是事件委托。与其给上千个列表项每个都绑定点击事件不如只给父容器绑一个监听器通过事件对象的target判断点击的是谁。这不仅减少内存还能让动态新增的节点天然拥有事件处理能力不用每次新增都重新绑定。4.3 “拥抱原生”不等于“抛弃框架”局部优化策略很多人听到“拥抱原生 DOM”会走极端觉得框架完全没用所有页面回到手写。这其实是最容易翻车的思路。框架真正的价值在于组织代码、维护状态、抽象组件这些能力是原生 DOM 不具备的。正确的打开方式是框架管架构原生管性能热点。我在实际项目中经常用的策略是一个大型表格组件状态和交互逻辑仍然写在 Vue/React 里但内部对超大列表渲染、滚动性能、高频单元格更新这类热点用原生 DOM 或 Canvas 单独做一个“渲染引擎层”来处理。这样既保持组件边界清晰又不牺牲性能。比如长列表虚拟滚动基本逻辑就是用原生 DOM 配合绝对定位只渲染可视区域内的节点框架只负责给渲染层喂数据。进入原生性能优化之前先问自己三个问题这里真的特别卡吗卡的原因是因为更新太频繁还是节点太多用框架的常规优化手段key、memo、虚拟滚动都试过了吗如果答案能走到“必须直接控制 DOM”再动手写原生代码。这样可以避免过早优化也避免把简单问题复杂化。4.4 从原生 DOM 学到的思维理解浏览器渲染管线抱着原生 DOM 写一段时间最大的收获其实是理解了浏览器的渲染管线HTML 解析成 DOMCSS 解析成 CSSOM两者合成渲染树然后进行布局、绘制、合成。框架的虚拟 DOM 也好原生操作也好最终都走这一条管线。理解了管线之后你写框架代码的思路也会变。比如你知道 CSS 动画尽量操作transform和opacity因为它们可以由合成器单独处理不触发布局你知道读scrollTop、offsetHeight这种布局属性前最好先把所有写入操作做完你也知道display: none到display: block的切换会触发整棵子树布局所以要谨慎。这些经验是虚拟 DOM 帮你挡掉的但你要是完全不懂遇到性能问题就只能瞎试。所以我一直觉得学习原生 DOM 的意义不只是“优化性能”它更像是一条理解浏览器底层脾气的捷径。框架终究是个抽象层而这个抽象层下面是什么、它是怎么运作的永远是前端工程师的分水岭。5. 选型实战一个数据中台项目里的三方抉择5.1 需求拆解从业务形态倒推技术路线光讲理论容易飘我用一个实际经历过的“某数据中台系统”来复盘。这个系统的核心页面有这么几块一个实时刷新的监控大屏包含大量动态图表一套标准化表单流程要给运营人员做审批还有一个可以展示几千行数据的复杂数据表格支持多级排序和单元格编辑。先做需求拆解把每个业务模块对应的技术诉求列出来业务模块技术诉求初步判断实时监控大屏每秒多次刷新、动画流畅、动态图形不适合用虚拟 DOM 硬抗Canvas 原生 DOM 更稳妥表单审批流程状态绑定、校验、联动逻辑清晰适合用框架的响应式能力Vue 或 React 都可以大数据表格长列表、单元格频繁更新、滚动平滑需要虚拟滚动和局部渲染原生 DOM 做渲染层全局导航和布局常规 UI变化不频繁框架组件化开发维护效率高这个表做完选型结论基本就不是“谁更好”的问题了而是“谁更适合当骨架谁更适合填血肉”。框架负责系统的主体结构原生 DOM 和 Canvas 负责最敏感的性能区块各司其职。5.2 落地过程中的关键决策与踩坑记录团队当时选择了 Vue 作为主框架理由是团队成员对 Vue 的模板写法和响应式语义更熟悉并且中后台业务里表单联动非常多Vue 的响应式系统能让这部分代码量少很多。然后做了两个关键决策第一监控大屏不放在普通页面里渲染而是做成一个独立的 Canvas 容器由定时器拉数据后直接画图第二大数据表格内部封装了一个“原生渲染层”用DocumentFragment批量更新可视区行数据。踩坑也很多。第一个坑就是列表 key 没做好当时有个同事图省事用了行号做 key结果表格排序功能一上线复选框的勾选状态全乱了。排查了很久才反应过来后来统一改成数据条目里的唯一 ID问题立刻消失。第二个坑是动画性能。大屏上有一个折线图数据是每秒更新一次最初用 SVG 更新整条折线路径CPU 占用一直下不来。后来拆成“只更新最后几个点对应的节点”并配合requestAnimationFrame来控制绘制频率CPU 占用降了一半还多。这种问题用框架思维是不好定位的因为框架不会告诉你“改的是哪几个节点”但原生 DOM 思维会让你直接盯住“变更范围最小化”。5.3 团队协作与后期维护的隐性成本原生 DOM 用得再爽也逃不过维护成本问题。如果每个人都在业务代码里到处写querySelector和appendChild那项目很快就会变得没法看。我们当时立了一个规矩所有直接操作 DOM 和 Canvas 的逻辑必须收敛到独立的内部渲染层组件里业务层只能通过暴露的方法或属性来操作不允许跳出渲染层直接抓 DOM。这样做的价值在后期才真正体现出来。有一位同事后来要加一个“列宽拖动”功能他只需要修改渲染层内部的事件监听逻辑业务层几乎没动。反过来如果我当时放任原生代码散落各处后期加任何功能都会变成捉迷藏。框架给了你组织能力原生给了你性能但两者结合的地方必须画清楚边界不然就是给未来埋雷。6. 常见问题与高频面试追问实录6.1 面试高频追问 TOP5这个组合问题之所以经典是因为它可以往各个方向深挖。我自己整理了几个出现频率最高的追问以及关键答法追问关键答法容易踩的坑key 到底有什么用让 diff 能识别节点身份实现复用和最小更新只说“性能优化”忽略状态错乱问题虚拟 DOM 一定比原生快吗不一定要看更新频率和变更范围无脑背书 “虚拟 DOM 更快”Vue 的响应式是怎么收集依赖的Proxy 拦截读取和写入建立依赖关系并触发更新说不清依赖收集和派发更新的时机React 中 memo / useMemo 解决了什么减少不必要的重新渲染缓存计算和引用滥用 memo 导致新旧比对反而更贵什么场景该拥抱原生 DOM高频细粒度更新、超大列表、复杂动画陷入“框架过时论”6.2 容易踩的认知误区我踩过的坑第一个误区是“虚拟 DOM 快”。我曾经也这么以为后来做性能排查才发现页面的瓶颈往往不在“JS 算得慢”而在“浏览器渲染得多”。虚拟 DOM 做的是防止不必要的渲染而不是让每次渲染都飞快。面对高频更新最有效的思路还是减小变更范围虚拟 DOM 帮你自动做了一部分剩下的一部分只有你能做。第二个误区是“框架里绝对不能碰原生 DOM”。其实框架都给你留了 ref 之类的逃生口关键问题是你能不能控制住边界。我见过把整个表格的数据渲染全部用原生 DOM 拼出来、完全绕开框架响应式的做法初看性能很猛但后续维护的人完全看不懂逻辑。真正成熟的用法是“局部、收敛、有边界”而不是“全盘替换”。第三个误区是“Vue 比 React 好 / React 比 Vue 好”这种一锤子定论。我参与过两种框架的项目感受是它们都在快速演进Vue 越来越重视组合式逻辑和工程化约束React 也在不断完善自动批处理和并发能力。选型的关键永远是“当前团队、当前业务、当前时间点”而不是哪一方更“先进”。把精力放在理解框架背后的渲染模型上比争论哪个框架更有前途有价值得多。最后再分享一条个人心得前端这条路工具迭代太快但底层逻辑不太变。只要你理解了“状态怎么流动、UI 怎么更新、浏览器怎么渲染”那无论是 Vue、React还是未来某个新框架你都只是换一套表达方式而已。虚拟 DOM 和原生 DOM 也不是互斥的它们只是不同粒度上的工具什么时候用谁靠的是对业务场景的判断而不是盲目的站队。希望这篇总结能让你少走一点我走过的弯路。