为什么 Lit 不需要 Virtual DOM —— 从架构与浏览器模型谈起

在第一次接触 Lit 时，很多有 React / Vue 背景的开发者都会产生一个疑问：

没有 Virtual DOM，Lit 是怎么高效更新 DOM 的？

甚至会进一步怀疑：

没有 Diff，会不会性能不行？

这篇文章不从“性能测试结果”出发，而是从架构选择与浏览器原生能力的角度，解释 Lit 为什么不需要 Virtual DOM，以及它背后的逻辑是否成立。

---

一、Virtual DOM 到底解决了什么问题？

在讨论 Lit 之前，先澄清一个常见误解：

Virtual DOM 并不是“为了性能而生”

它最初解决的是两个问题：

1. 抽象 DOM 操作

• 手写 DOM 操作复杂、易错
• UI = f(state) 的声明式模型更易维护

---

2. 跨平台渲染能力

• DOM / Native / Canvas
• 同一套 UI 描述，映射到不同平台

---

1.1 Diff 的真正作用

Diff 并不是为了“快”，而是为了：

在不知道哪些节点会变的前提下，找到变化点

这是一个兜底策略。

---

二、Virtual DOM 的隐含前提

Virtual DOM 能成立，依赖一个关键前提：

框架并不知道“哪一部分 DOM 会变”

因此只能：

state 改变
  ↓
重新生成整棵 VDOM
  ↓
Diff 新旧 VDOM
  ↓
计算最小 DOM Patch

这在复杂 UI 场景下是非常合理的设计。

---

三、Lit 的核心不同点：它“提前知道变化点”

Lit 的设计前提与 React / Vue 完全不同：

模板结构是稳定的，变化的只有表达式

这句话非常关键。

---

3.1 模板在 Lit 中是“一次性解析”的

html`<p>Hello ${name}</p>`

第一次执行时，Lit 会做一件事：

• 把模板解析成 静态结构
• 把 ${name} 标记为一个“可更新点”

之后模板结构不会再变。

---

3.2 Lit 的更新目标非常明确

只更新 ${} 对应的位置

而不是“猜测哪里变了”。

---

四、lit-html 的核心抽象：Part

Lit 用一个非常重要的概念替代了 Virtual DOM：

Part（局部更新单元）

---

4.1 什么是 Part

Part 表示 DOM 中一个确定的、可更新的位置。

例如：

<p>Hello <!--part--></p>

---

4.2 Part 的类型

Part 类型	对应更新
ChildPart	文本 / 子节点
AttributePart	普通属性
PropertyPart	DOM property
BooleanAttributePart	布尔属性
EventPart	事件

这些 Part 在首次渲染时就已经确定。

---

五、Lit 的更新流程（没有 Diff）

5.1 更新路径

state 改变
  ↓
render() 再执行
  ↓
得到新的 values
  ↓
逐个 Part.update(value)

注意：

• 没有树结构对比
• 没有节点遍历
• 没有启发式 Diff

---

5.2 对比 Virtual DOM 的更新路径

React / Vue：

state → VDOM → diff → patch DOM

Lit：

state → values → 精确更新 DOM

Lit 的路径更短，是因为它不需要推断变化点。

---

六、为什么这在性能上是成立的？

6.1 少做事，往往就是最快的

Virtual DOM 的性能成本主要来自：

• VDOM 对象创建
• 树遍历
• Diff 算法
• 内存分配与 GC

Lit 完全绕过了这些步骤。

---

6.2 DOM 操作真的很慢吗？

一个常见误区是：

“DOM 操作很慢，所以要避免”

事实上：

• 多余的 DOM 操作才慢
• 精确的 DOM 操作非常快

Lit 正是第二种情况。

---

七、为什么 React / Vue 不能这么做？

因为它们面对的是更复杂的场景：

• JSX / Template 高度动态
• 组件结构本身可变
• 插槽、条件渲染、Fragment
• 跨平台渲染需求

Lit 的约束更多，但换来了：

更低的复杂度与更小的运行时

---

八、Lit 的“代价”：你必须遵守规则

Lit 的高效并不是免费的。

8.1 模板结构必须稳定

html`
  ${condition ? html`<a>` : html`<div>`}
`

这种写法是可以的，但你需要理解：

• Lit 会为嵌套模板创建新的 Part
• 复杂度会随之上升

---

8.2 Lit 不适合“结构高度不确定的 UI”

如果你需要：

• 大量动态插槽
• 深度条件结构切换
• 复杂动画协调

React / Vue 可能更合适。

---

九、一个关键结论（IImportant）

Virtual DOM 是“不确定性下的最优解”
Lit 是“确定性前提下的最优解”

它们解决的问题本就不同。

---

十、总结

• Lit 不使用 Virtual DOM，并不是“少了功能”
• 而是通过 模板确定性 + Part 定点更新 绕过了 Diff
• 这是一个更接近浏览器模型的设计

如果你理解了这一点，就会发现：

Lit 并不是“简化版 React”
而是“另一条技术路线”