企业官网建设流程全解析

前端圈子里有一个很有意思的现象：你去面技术岗，大概率会被问到一个组合包——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 一张对比表和我常用的选型判断流程

我自己的选型流程很简单：先列业务形态，再列团队画像。如果你要在一个月内交付一个管理后台，团队以二三年经验同学为主，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 解析成 DOM，CSS 解析成 CSSOM，两者合成渲染树，然后进行布局、绘制、合成。框架的虚拟 DOM 也好，原生操作也好，最终都走这一条管线。

理解了管线之后，你写框架代码的思路也会变。比如，你知道 CSS 动画尽量操作transform和opacity，因为它们可以由合成器单独处理，不触发布局；你知道读scrollTop、offsetHeight这种布局属性前，最好先把所有写入操作做完；你也知道display: none到display: block的切换会触发整棵子树布局，所以要谨慎。这些经验是虚拟 DOM 帮你挡掉的，但你要是完全不懂，遇到性能问题就只能瞎试。

所以我一直觉得，学习原生 DOM 的意义不只是“优化性能”，它更像是一条理解浏览器底层脾气的捷径。框架终究是个抽象层，而这个抽象层下面是什么、它是怎么运作的，永远是前端工程师的分水岭。

5. 选型实战：一个数据中台项目里的三方抉择

5.1 需求拆解：从业务形态倒推技术路线

光讲理论容易飘，我用一个实际经历过的“某数据中台系统”来复盘。这个系统的核心页面有这么几块：一个实时刷新的监控大屏，包含大量动态图表；一套标准化表单流程，要给运营人员做审批；还有一个可以展示几千行数据的复杂数据表格，支持多级排序和单元格编辑。

先做需求拆解，把每个业务模块对应的技术诉求列出来：

这个表做完，选型结论基本就不是“谁更好”的问题了，而是“谁更适合当骨架，谁更适合填血肉”。框架负责系统的主体结构，原生 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

这个组合问题之所以经典，是因为它可以往各个方向深挖。我自己整理了几个出现频率最高的追问，以及关键答法：

6.2 容易踩的认知误区，我踩过的坑

第一个误区是“虚拟 DOM = 快”。我曾经也这么以为，后来做性能排查才发现，页面的瓶颈往往不在“JS 算得慢”，而在“浏览器渲染得多”。虚拟 DOM 做的是防止不必要的渲染，而不是让每次渲染都飞快。面对高频更新，最有效的思路还是减小变更范围，虚拟 DOM 帮你自动做了一部分，剩下的一部分只有你能做。

第二个误区是“框架里绝对不能碰原生 DOM”。其实框架都给你留了 ref 之类的逃生口，关键问题是你能不能控制住边界。我见过把整个表格的数据渲染全部用原生 DOM 拼出来、完全绕开框架响应式的做法，初看性能很猛，但后续维护的人完全看不懂逻辑。真正成熟的用法是“局部、收敛、有边界”，而不是“全盘替换”。

第三个误区是“Vue 比 React 好 / React 比 Vue 好”这种一锤子定论。我参与过两种框架的项目，感受是它们都在快速演进，Vue 越来越重视组合式逻辑和工程化约束，React 也在不断完善自动批处理和并发能力。选型的关键永远是“当前团队、当前业务、当前时间点”，而不是哪一方更“先进”。把精力放在理解框架背后的渲染模型上，比争论哪个框架更有前途有价值得多。

最后再分享一条个人心得：前端这条路，工具迭代太快，但底层逻辑不太变。只要你理解了“状态怎么流动、UI 怎么更新、浏览器怎么渲染”，那无论是 Vue、React，还是未来某个新框架，你都只是换一套表达方式而已。虚拟 DOM 和原生 DOM 也不是互斥的，它们只是不同粒度上的工具，什么时候用谁，靠的是对业务场景的判断，而不是盲目的站队。希望这篇总结能让你少走一点我走过的弯路。