首页 > 基础资料 博客日记
虚拟 DOM —— 中间层的智慧
2026-06-12 10:30:01基础资料围观3次
操作真实 DOM 有多贵?
先看一段代码:
// 把一个 <div> 的背景色改成红色
document.getElementById('box').style.backgroundColor = 'red'
你觉得这一行代码的执行成本是多少?
答案远比你想象的复杂:
1. JS 引擎找到 DOM 节点
2. 修改 DOM 节点的 style 属性
3. 浏览器标记这个节点需要重新计算样式(Recalculate Style)
4. 重新布局(Layout/Reflow)—— 可能影响周围元素的位置
5. 重新绘制(Paint)—— 把新的颜色画到屏幕上
6. 合成(Composite)—— 把各层合成最终画面
修改一个属性可能触发整个渲染流水线。
如果是 1000 个属性修改呢?如果是添加、删除、移动几百个节点呢?
直接操作真实 DOM 就像在沙滩上写字——每一笔都很简单,但改一个字就可能要抹平整个沙滩。
虚拟 DOM 是什么?
虚拟 DOM 就是用普通的 JavaScript 对象来描述一个 DOM 节点。
真实 DOM:
<div id="app" class="container">
<p>Hello</p>
</div>
等价的虚拟 DOM:
{
tag: 'div',
props: { id: 'app', class: 'container' },
children: [
{
tag: 'p',
props: {},
children: [
{ tag: undefined, text: 'Hello' } // 文本节点
]
}
]
}
Vue 中把这个 JS 对象叫做 VNode(Virtual Node)。
为什么不用真实 DOM,要自己造一个?
用一张表来对比:
| 真实 DOM | 虚拟 DOM (VNode) | |
|---|---|---|
| 本质 | C++ 实现的浏览器对象 | 普通 JS 对象 |
| 创建成本 | 高(创建几百个属性) | 低(就几个字段) |
| 操作成本 | 高(可能触发回流) | 低(只是改 JS 对象) |
| 跨平台 | 只能在浏览器 | 可以渲染到不同平台 |
| 可控性 | 浏览器说了算 | 框架完全控制 |
核心思想:
用廉价的 JS 对象操作代替昂贵的 DOM 操作。先在 JS 层面做完所有计算,最后一次性、最少化地更新真实 DOM。
打个比方:装修房子
你要重新装修一个房间,有两种方式:
方式一:直接施工(直接操作 DOM)
"把左边这面墙砸掉" → 工人开始砸
"等等,右边那面也砸" → 工人换位置砸
"不对,左边还是留着吧" → 工人:???
每次指示都立刻执行,改主意了就返工。工期长、成本高。
方式二:先在图纸上画(虚拟 DOM)
在图纸上画一遍 → 对比旧图纸 → 标记出所有改动 → 一次施工完成
先在纸上(JS 内存)把所有方案画好,确认无误后,列出最小改动清单,一次性施工。
虚拟 DOM 就是那张"设计图纸"。
Diff 算法:怎么找出最小改动?
现有一棵旧的 VNode 树和一棵新的 VNode 树,怎么找出"最少改动"?
把两棵树完全比较的时间复杂度是 O(n³)——对一棵有 1000 个节点的树来说,这是 10 亿次比较,不可接受。
但前端有一个重要的观察:大部分情况下,跨层级的移动非常罕见。
基于这个假设,Vue(和 React)的 diff 算法做了一个简化:
只比较同一层级的节点。不同层级的直接替换,不尝试"移动"到另一层。
这样算法退化到 O(n),即每个节点只比较一次。
同层 Diff 的三个步骤
Vue 的 diff 采用的是双端比较策略。以下以子节点数组的 diff 为例。
假设旧子节点是 [A, B, C, D],新子节点是 [B, A, D, E]。
步骤 1:头头比较
旧: [A, B, C, D]
↑
新: [B, A, D, E]
↑
A !== B → 不匹配,结束头头比较
步骤 2:尾尾比较
旧: [A, B, C, D]
↑
新: [B, A, D, E]
↑
D !== E → 不匹配,结束尾尾比较
步骤 3:头尾交叉比较
旧头 vs 新尾: A vs E → 不匹配
旧尾 vs 新头: D vs B → 不匹配
此时四个指针都没匹配上,说明需要更复杂的操作。Vue 会尝试在旧节点中查找新节点是否存在(通过 key)。
如果设置了 key
<div v-for="item in list" :key="item.id">
key 的作用就是给每个 VNode 一个唯一的身份标识,让 diff 算法能识别出"这个节点只是位置变了,不是被删除重建了"。
旧: [{key:'A'}, {key:'B'}, {key:'C'}, {key:'D'}]
新: [{key:'B'}, {key:'A'}, {key:'D'}, {key:'E'}]
有 key 时:
B 在旧节点中找到 → 移动位置即可
A 在旧节点中找到 → 移动位置即可
D 在旧节点中找到 → 移动位置即可
E 不在旧节点中 → 新建
无 key 时:
可能把 B 当成了 A(因为都是第一个位置)
→ 更新 A 的内容为 B,而不是移动
→ 效率低,还可能导致状态丢失
动手实现一个迷你 VNode + Diff
VNode 创建
function createVNode(tag, props, children) {
return { tag, props, children }
}
function h(tag, props, ...children) {
return createVNode(tag, props, children.flat())
}
将 VNode 渲染为真实 DOM
function mount(vnode, container) {
// 创建元素
const el = document.createElement(vnode.tag)
// 设置属性
if (vnode.props) {
for (const key in vnode.props) {
el.setAttribute(key, vnode.props[key])
}
}
// 处理子节点
if (vnode.children) {
vnode.children.forEach(child => {
if (typeof child === 'string') {
el.appendChild(document.createTextNode(child))
} else {
mount(child, el) // 递归挂载
}
})
}
container.appendChild(el)
vnode.el = el // 保存对真实 DOM 的引用
}
Diff 和 Patch
function patch(oldVNode, newVNode) {
const el = (newVNode.el = oldVNode.el)
// 1. 标签不同 → 直接替换
if (oldVNode.tag !== newVNode.tag) {
const newEl = document.createElement(newVNode.tag)
el.parentNode.replaceChild(newEl, el)
mount(newVNode, el.parentNode)
return
}
// 2. 更新属性
// 移除旧属性
for (const key in oldVNode.props) {
if (!(key in newVNode.props)) {
el.removeAttribute(key)
}
}
// 设置新属性
for (const key in newVNode.props) {
if (oldVNode.props[key] !== newVNode.props[key]) {
el.setAttribute(key, newVNode.props[key])
}
}
// 3. 更新子节点
const oldChildren = oldVNode.children || []
const newChildren = newVNode.children || []
const len = Math.max(oldChildren.length, newChildren.length)
for (let i = 0; i < len; i++) {
if (i >= oldChildren.length) {
// 新节点,直接挂载
mount(newChildren[i], el)
} else if (i >= newChildren.length) {
// 旧节点多余,删除
el.removeChild(oldChildren[i].el)
} else {
// 都存在,递归 patch
if (typeof oldChildren[i] === 'string' && typeof newChildren[i] === 'string') {
if (oldChildren[i] !== newChildren[i]) {
el.childNodes[i].textContent = newChildren[i]
}
} else {
patch(oldChildren[i], newChildren[i])
}
}
}
}
上面是最简版本的实现,省略了 key 的匹配逻辑,但已经能说明 Diff 的核心思想:同层比较,最小化 DOM 操作。
虚拟 DOM vs 直接操作 DOM:到底谁更快?
这是一个经典争论。答案是:
一般情况下,直接操作 DOM 可以比虚拟 DOM 更快。但虚拟 DOM 能让你写出的代码足够好、足够可维护,同时性能"足够快"。
| 场景 | 直接操作 DOM | 虚拟 DOM |
|---|---|---|
| 单个更新 | ✅ 更快 | 🟡 有 diff 开销 |
| 批量更新 | 🤷 需要手动优化 | ✅ 自动合并 |
| 代码可维护性 | ❌ 散落各处 | ✅ 声明式 |
| 跨平台 | ❌ 仅浏览器 | ✅ 可渲染到原生 |
虚拟 DOM 不是性能的最优解,而是"开发体验 + 足够好的性能"之间的最优平衡。
总结
- 为什么需要虚拟 DOM:真实 DOM 操作成本高,虚拟 DOM 在 JS 层完成计算,最后一次性最少地更新真实 DOM。
- VNode:用 JS 对象描述 DOM 节点,创建和比较成本极低。
- Diff 算法:同层比较,O(n) 复杂度。双端比较 + key 优化是最核心的策略。
- Key 的作用:给节点唯一标识,让 Diff 能区分"移动"和"替换"。
- 性能本质:虚拟 DOM 是"足够快 + 足够好维护"的平衡方案。
有了虚拟 DOM,Vue 就知道"视图应该长什么样"。但视图是由组件构成的——组件是怎么创建、挂载、更新的?
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!
标签:
相关文章
最新发布
- 为什么你的收藏越积越多,却越来越没用?
- 42 倍小文件性能提升、85% 吞吐增长:多云 AI 场景下的 JuiceFS 存储实践
- SkyWalking / Jaeger / ARMS 已经有了,还需要统一可观测平台吗
- How LLMs Actually Work(翻译)
- 数据库审计不是记流水账:先锁定高危动作与关键对象,再谈数据集与工具落地
- 用了 lark-cli 一个月,AI 操作飞书再也没出过岔子——说说真实体验
- Claude Code 配置第三方模型后,内置工具到底用的谁的?
- 虚拟 DOM —— 中间层的智慧
- Spring Cloud Gateway 的 SpEL 表达式注入漏洞(CVE-2022-22947)
- AI 测试赋能全流程实战 | Agent Skill + AI 赋能「需求分析」

