虚拟 DOM
虚拟 DOM 作为界面结构的中间表示，如何承接渲染计算与真实 DOM 更新。
[!info] related notes
虚拟 DOM
虚拟 DOM 是前端框架常见的一层中间表示，用来描述“界面长什么样”，并帮助框架计算状态变化后需要更新哪些真实 DOM。
一句话定义
虚拟 DOM 不是浏览器里的真实节点，而是用 JavaScript 对界面结构做的对象化描述。
它解决什么问题
- 让框架先在内存中计算新旧界面差异
- 降低开发者直接手写 DOM 更新逻辑的复杂度
- 为组件化更新、条件渲染、列表渲染提供统一模型
一条最稳的主线
- 状态变化
- 生成新的虚拟 DOM
- 和旧虚拟 DOM 比较
- 把必要差异更新到真实 DOM
它和 React 渲染到底是什么关系
在 React 里，更值得记住的不是“虚拟 DOM 很快”，而是：
- 组件重新执行后会得到新的元素描述
- React 再基于前后描述判断真实界面要改哪里
所以虚拟 DOM 更像 React 渲染链路里的中间表示层，而不是性能神药。
为什么它常和“重渲染”一起被误解
很多人会把：
- 组件函数重新执行
- 生成新的虚拟 DOM 描述
- 提交真实 DOM 更新
误以为是一回事。
更准确的理解应该是：
- rerender 先发生在组件执行层
- 虚拟 DOM 承接新的结构描述
- 真实 DOM 只做必要更新
为什么它常和 key 一起出现
因为框架在比较列表节点时，需要知道“哪个节点还是原来的那个节点”，而 key 就是在提供身份信息。
常见误区
- 虚拟 DOM 不等于永远更快
- 虚拟 DOM 不等于完全不操作真实 DOM
- 理解它不能脱离具体更新流程和框架运行时
- 不能把“用了虚拟 DOM”理解成“性能天然没问题”
最短记忆方式
虚拟 DOM 是框架在状态和真实 DOM 之间放的一层中间表示。
面试要点
来自 key-attribute-interview-question 的面试视角整理。
一句话回答
虚拟 DOM 是对界面结构的 JavaScript 描述，框架会先基于它计算新旧界面差异，再把必要变化同步到真实 DOM。
最稳的回答主线
- 它不是浏览器真实 DOM
- 它让框架可以先在内存中组织更新
- 它的价值是统一更新模型，而不只是单纯追求快
一个更完整的面试表达
可以这样答：
虚拟 DOM 本质上是对界面结构的一层 JavaScript 描述。框架在状态变化后，会先生成新的界面描述，再和旧描述比较，最后把必要变化同步到真实 DOM。
它的重要价值不只是性能，而是给组件化和声明式更新提供了一套统一的运行时模型。
一条最稳的更新主线
- 状态变化
- 生成新的虚拟 DOM 描述
- 和旧描述比较
- 只把必要变化更新到真实 DOM
一个常见误区
不要把“组件 rerender”直接等同于“真实 DOM 全量重建”。
更准确的理解是：
- 组件函数会重新执行
- 框架会得到新的结构描述
- 真实 DOM 只做必要变更
面试里一句加分点
虚拟 DOM 不等于任何场景都更快，它更重要的价值是让组件化和声明式更新有一套统一的运行时模型。
最短记忆方式
虚拟 DOM 是框架更新真实 DOM 前的中间层。
一句话回答
key 的作用是让框架在前后两次渲染之间识别“哪个节点还是原来的那个节点”，从而更可靠地复用和更新列表项。
最稳的回答主线
key提供节点身份- 没有稳定
key，列表更新就更容易错位复用 - 插入、删除、排序时，随便用 index 风险最大
一个更完整的面试表达
可以这样答：
key的核心作用不是消除 React 的警告，而是告诉框架“前后两次渲染里，哪个节点还是原来的那个节点”。
列表更新时，框架需要基于节点身份来决定复用、移动还是销毁。如果key不稳定，尤其是用 index，在插入、删除、排序场景里就容易出现错位复用。
为什么 index 容易出问题
如果列表顺序会变，index 代表的是“位置”，不是“业务身份”。
所以一旦头部插入一个元素，后面所有项的 index 都会变，框架就可能把“同位置的新节点”误认为“原来的旧节点”。
常见后果
- 输入框内容串位
- 组件局部状态复用错误
- 动画和过渡表现异常
一个更工程化的结论
最好的 key 通常来自稳定业务 id，而不是渲染时临时凑出来的位置值。
最短记忆方式
key 不是消警告用的，是给节点立身份证用的。