后Virtual DOM时代：Vue Vapor Mode 与 React Compiler 如何把虚拟DOM逼向终点——从信号依赖追踪到编译期DOM直写全链路拆解

2026 年，前端框架的底层假设正在发生十年未有的松动。Vue 3.6 把 Vapor Mode 推到生产就绪，React Compiler 在 2026 年稳定，Solid、Svelte、Angular Signals 把"信号"变成了基础设施。虚拟DOM 这个统治了前端十年的抽象，第一次被从两个方向同时夹击：编译期把模板直接翻译成 DOM 操作，以及运行期用细粒度信号做 O(1) 的精准更新。本文不吹水，从 30 行代码讲清虚拟DOM 的真实代价，再手写一个能跑的响应式系统和一个能跑的迷你虚拟DOM，最后用基准测试把"更新一万条里的某一条"这件事的复杂度摊开给你看。

一、背景介绍：虚拟DOM 为什么会被"逼宫"

1.1 虚拟DOM 解决了什么问题

2013 年 React 把"声明式 UI"带进主流，核心武器是虚拟DOM（Virtual DOM，下文简称 VDOM）。它的故事很性感：你只描述 UI 应该是什么样子，框架负责把"现在"和"上一次"的差异算出来，再打到真实 DOM 上。

在 VDOM 之前，前端的主流做法是命令式操作真实 DOM：

// jQuery 时代的命令式更新：你既知道"要变成什么"，也得自己算"怎么变"
function renderUser(user) {
  $('#name').text(user.name);
  $('#avatar').attr('src', user.avatar);
  $('#bio').text(user.bio);
}

问题很明显：状态一多，命令式代码就退化成一张"哪里变了改哪里"的脆弱补丁网。VDOM 把这个问题换成了一个更干净的表述——

// 声明式：你永远根据"完整状态"描述完整 UI，diff 交给框架
function UserCard({ user }) {
  return (
    <div>
      <img src={user.avatar} />
      <h3>{user.name}</h3>
      <p>{user.bio}</p>
    </div>
  );
}

这个抽象在 2013 年是降维打击：开发者不再手写 diff，框架用统一的协调（reconciliation）算法兜底。这是 VDOM 真正的价值，直到今天它依然成立。

1.2 但 VDOM 的"免费午餐"是有账单的

VDOM 的代价被早期宣传严重低估了。很多人以为"diff 比直接操作 DOM 快"，这是误区——diff 永远比不 diff 慢，VDOM 快，是快在它用廉价的 JS 对象对比，替代了昂贵的真实 DOM 读写，而不是因为 diff 本身免费。

更关键的是，VDOM 的更新单位是"组件"。当组件 re-render 时，会发生三件事：

1. 重建 VNode 树：重新执行组件的 render 函数，创建一整棵新的虚拟节点对象（哪怕只有一个叶子变了）。
2. diff 比对：把新树和旧树做递归比较。
3. commit 打补丁：把差异应用到真实 DOM。

这三步的成本都和"组件子树的大小"成正比，而不是和"真正变化的节点数"成正比。换句话说，VDOM 的复杂度是 O(子树规模)，不是 O(变化量)。这在大多数交互里够用，但在高频、细粒度的更新场景（实时仪表盘、协同编辑光标、大规模列表里的单行更新）下，这个"每次都重算整棵子树"的模型就成了性能天花板。

1.3 2026 的拐点：三股力量同时撞向 VDOM

2026 年，三件事把"VDOM 是不是必须的"推成了行业级话题：

• Vue 3.6 把 Vapor Mode 推到生产就绪。Vapor Mode 在编译期把模板编译成直接操作 DOM 的命令式代码，运行时不再创建 VNode，但完整保留 Vue 的响应式系统。
• React Compiler 在 2026 年稳定。它用静态分析自动插入 memo/useMemo/useCallback，把"该重渲染的才重渲染"从人工纪律变成编译器保证——本质上是在 VDOM 内部做"减法"。
• 信号（Signals）成为跨框架共识。Solid、Svelte 早已是信号派；Angular Signals 在 2024 年落地；连 Preact 都提供了 Signals。TC39 甚至有了 Signals 标准提案，要把这套原语标准化进语言层。

这三股力量指向同一个结论：虚拟DOM 正在从"唯一的真相"退居为"众多策略里的一种"。本文要回答的核心问题是：

VDOM、编译期直写、细粒度信号，三者的本质区别到底是什么？它们各自在什么场景下赢？作为工程师，2026 之后该怎么选？

二、核心概念：把"更新"这件事拆开看

要真正看懂这场架构之争，得先把"更新一个 UI"拆成两层独立的问题：

1. 何时更新（When）：框架怎么知道"哪些地方依赖于这个状态"？
2. 如何更新（How）：知道要更新后，怎么把变化落到 DOM 上最高效？

2.1 两条哲学：自顶向下的协调 vs 自底向上的传播

VDOM 哲学是自顶向下的协调（Top-down Reconciliation）：

状态变了 → 组件函数重新执行 → 生成新的整棵树 → 和旧树 diff → 打补丁。

它的好处是"简单且正确"：你永远拿到的是"完整的最新状态描述"，框架不用预先知道依赖关系，靠 diff 兜底。坏处就是前面说的 O(子树规模)。

信号哲学是自底向上的传播（Bottom-up Propagation）：

状态（信号）变了 → 框架已经预先记录了"谁订阅了我" → 只通知这些订阅者 → 订阅者直接改自己那一小块 DOM。

它的好处是"精准、O(1)"：更新成本只和"真正变化的节点"有关。坏处是框架必须在运行时精确追踪依赖关系，这套追踪机制本身就是复杂度。

2.2 依赖追踪的本质：一个全局"当前观察者"栈

信号能实现"自底向上传播"，靠的是一个极简但精妙的模式——依赖收集 + 发布订阅。核心只有一句话：

当某个"副作用"（effect）读取了一个信号的值，就把这个 effect 登记为该信号的订阅者；之后信号被写入时，通知所有订阅者重跑。

实现它只需要一个全局的"当前正在执行的观察者"指针：

// 全局：当前正在执行的 effect（依赖收集的目标）
let activeEffect = null;
const effectStack = [];

// 读取信号时，如果正在执行 effect，就把 effect 登记为订阅者
// 写入信号时，通知所有订阅者重跑

这就是细粒度响应式的全部奥秘。后面 4.1 节我们会完整实现它。

2.3 关键指标：渐进复杂度

把"更新一个列表里第 N 条记录的某个字段"作为基准操作：

• VDOM（无 memo）：组件重渲染 → 重建整棵列表 VNode（假设 K 条）→ diff K 条 → O(K)。K 越大越慢。
• VDOM + 精准 memo：只有那一条所在的组件重渲染，但依然要重建该组件的 VNode 子树并 diff。O(该组件子树规模)。
• 信号 / 编译直写：只有那一个文本节点被更新，O(1)，与列表总长无关。

注意一个容易混淆的点：O(1) 不等于"绝对更快"。当一次更新天然要改"一大片"（比如整页主题切换），VDOM 一次性 diff 反而可能比信号逐个通知更省。但凡是"高频 + 局部"的更新，信号派在渐进复杂度上就是降维打击。

三、架构分析：三家各自怎么出招

3.1 Vue Vapor Mode：保留响应式，丢掉 VNode

Vue 的响应式系统（ref / reactive / computed）从 Vue 3 起就是细粒度的——它本来就是用依赖追踪实现的。但 Vue 3 的渲染层仍然走 VDOM：模板编译成 render 函数，返回 VNode，再 diff。

Vapor Mode 要做的事非常聪明：渲染层也编译掉。编译器读你的模板，直接生成"命令式操作 DOM"的代码，不再有 VNode 这层中间表示。

看同一段模板在两种模式下的产物差异（示意）：

// 普通 Vue 3 运行时（简化示意）：先造 VNode 再 diff
export function render(_ctx, _cache) {
  return createVNode('button', {
    onClick: () => _ctx.count++
  }, _ctx.count)
}

// Vapor Mode（简化示意）：直接操作 DOM，没有 VNode
export function render(_ctx, _el) {
  const btn = _el;
  // 编译期生成的 effect：count 变化时只改 textContent
  templateEffect(() => {
    setText(btn, _ctx.count);
  });
  btn.addEventListener('click', () => _ctx.count++);
}

关键洞察：Vapor Mode 没有发明新的响应式，它复用 Vue 已有的信号级依赖追踪，只是把"渲染"这一步从 VDOM 路径换成了编译期直写。所以 Vue 用户迁移成本极低——大部分组件只是加一个开关就能享受"无 VNode"的收益：

<!-- 在 <script setup> 里声明 vapor: true 即可启用 Vapor Mode -->
<script setup vapor>
import { ref } from 'vue'
const count = ref(0)
</script>

<template>
  <button @click="count++">点击了 {{ count }} 次</button>
</template>

Vapor Mode 是渐进式、可混用的：一个应用里可以部分组件走 Vapor、部分走经典运行时，因为两者共享同一套响应式内核。这是 Vue 相比"推倒重来"最务实的一点。

3.2 React Compiler：不放弃 VDOM，把"重渲染边界"交给编译器

React 官方对"VDOM 太重"的回答，和 Vue 不一样。React 没有去掉 VDOM，而是用 React Compiler 把"该不该重渲染"这个问题自动化。

React 的性能模型长期依赖开发者手动纪律：useMemo、useCallback、React.memo、正确的 key。漏写一处，组件就会在父级重渲染时无辜跟着重渲染。React Compiler 的做法是：静态分析组件的数据流，自动在需要的地方插入 memo 边界。

// 以前：你必须手动告诉 React "sorted 要被缓存、items 变了才算变"
function ProductList({ items }) {
  const sorted = useMemo(() => [...items].sort(byPrice), [items]);
  const onBuy = useCallback((id) => buy(id), []);
  return <ul>{sorted.map(i => <Row key={i.id} item={i} onBuy={onBuy} />)}</ul>;
}

// 现在：React Compiler 读懂数据流，自动插入等价 memo，你写"裸"代码即可
function ProductList({ items }) {
  const sorted = [...items].sort(byPrice);
  const onBuy = (id) => buy(id);
  return <ul>{sorted.map(i => <Row key={i.id} item={i} onBuy={onBuy} />)}</ul>;
}

接入方式就是加一个 Babel 插件（以 Vite 为例）：

// vite.config.js
import react from 'vite-plugin-react';
export default {
  plugins: [react({ babel: { plugins: ['babel-plugin-react-compiler'] } })],
};

Vapor Mode 与 React Compiler 的本质区别，必须讲清楚：

• Vue Vapor：在渲染层移除 VDOM，直接写 DOM，更新路径是信号级 O(1)。
• React Compiler：保留 VDOM 和协调器，只是用编译器消灭"无谓的重渲染"，把"该重渲染的才重渲染"自动化。它把 O(子树规模) 里的"子树"尽量压小，但每次更新本质上仍然是"组件函数重跑 + 生成 VNode + diff"这条路。

所以 Vue Vapor 是"换引擎"，React Compiler 是"给老引擎装自动变速箱"。两者都让 VDOM 的体验更好，但底层哲学不同。

关于"无虚拟DOM 版 React"：2026 年中行业里有关于 React 实验性"无 VDOM"方向（被一些媒体称为 Octane）的讨论，但截至本文撰写，React 官方在 2026 年落地的、生产可用的答案是 React Compiler，而非抛弃 VDOM。把"React 要去掉 VDOM"当成既定事实是不严谨的——准确说法是：React 选择了"编译器优化 VDOM"而非"编译期直写 DOM"的路线。

3.3 Solid.js：信号即一等公民，组件只跑一次

如果说 Vue Vapor 是"在 VDOM 框架里加信号渲染"，那 Solid.js 就是为信号而生的框架。它的核心信条是：组件函数只执行一次，不是每次状态变化都重跑；状态变化由信号直接在 DOM 上做精准更新。

import { createSignal, For, createEffect } from 'solid-js';

function TodoList() {
  const [todos, setTodos] = createSignal([
    { id: 1, text: '理解信号', done: false },
    { id: 2, text: '手写响应式', done: false },
  ]);

  return (
    <ul>
      <For each={todos()}>
        {(todo) => (
          <li class={todo.done ? 'done' : ''}>
            {/* 注意：这里 todo.text() 是函数调用，
                编译后变成"仅当 text 变时才更新这个文本节点" */}
            {todo.text}
          </li>
        )}
      </For>
    </ul>
  );
}

Solid 的 JSX 编译后大致是：

// 编译产物示意：组件函数只跑一次，创建 DOM 节点
// 每个读取信号的地方被包进一个 effect，信号变 → 只更新那一个节点
function TodoList() {
  const [todos, setTodos] = createSignal([/* ... */]);
  const ul = document.createElement('ul');
  for (const todo of todos()) {
    const li = document.createElement('li');
    // 编译期把 {todo.text} 变成 effect：text 变 → 只改 li.textContent
    createEffect(() => { li.textContent = todo.text(); });
    ul.appendChild(li);
  }
  return ul;
}

和 Vue Vapor 的异曲同工之处在于：两者最终都落到"信号变 → 精准改 DOM 节点"。区别在于 Solid 把信号放在了语言层面（组件即一次性执行），Vue 则把信号藏在响应式系统里、对开发者更透明。

3.4 一张对照表，看清三派

结论先行：2026 之后不会是"谁消灭谁"，而是"分层"——热路径（高频局部更新）用信号/编译直写，冷路径（低频整页）用声明式 VDOM 依然舒服。

四、代码实战：手写两个内核，再写三版对照

光讲不练是耍流氓。下面两段代码都能直接 node 跑（DOM 操作用极简 mock 代替，便于在 Node 里复现），读完你会对两种模型的内存行为有肌肉记忆。

4.1 手写一个能跑的细粒度响应式系统

这是全文的精华。我们要实现三个原语：createSignal、createEffect、createComputed，核心是依赖收集栈。

// mini-reactive.js —— 一个最小但正确的细粒度响应式系统
// 运行环境：Node（DOM 用 mock 代替，便于观察写入次数）

// ---- 全局依赖收集基础设施 ----
let activeEffect = null;          // 当前正在执行的 effect
const effectStack = [];           // 支持 effect 嵌套

// ---- 信号：可读可写的最小状态单元 ----
function createSignal(initial) {
  let value = initial;
  const subscribers = new Set();  // 订阅者集合

  // read：被 effect 读取时，把当前 effect 登记为订阅者
  function read() {
    if (activeEffect) {
      subscribers.add(activeEffect);
      activeEffect.deps.push(subscribers);
    }
    return value;
  }

  // write：值变了，通知所有订阅者重跑
  function write(next) {
    if (Object.is(next, value)) return; // 同值不触发，避免无效更新
    value = next;
    // 复制一份再遍历，防止 effect 重跑时修改原 Set 导致迭代异常
    [...subscribers].forEach((fn) => fn());
  }

  return [read, write];
}

// ---- effect：副作用，读取信号时建立订阅 ----
function createEffect(fn) {
  const effectFn = () => {
    cleanup(effectFn);            // 先清掉旧依赖，再重新收集（应对条件分支）
    activeEffect = effectFn;
    effectStack.push(effectFn);
    try {
      return fn();
    } finally {
      effectStack.pop();
      activeEffect = effectStack[effectStack.length - 1] ?? null;
    }
  };
  effectFn.deps = [];             // 记录本 effect 订阅了哪些信号
  effectFn();                     // 立即执行一次，完成首次依赖收集
  return effectFn;
}

// 清除 effect 在旧信号上的订阅，避免"过期依赖"导致误更新
function cleanup(effectFn) {
  for (const dep of effectFn.deps) dep.delete(effectFn);
  effectFn.deps.length = 0;
}

// ---- computed：派生态，依赖变时自动重算并通知自己的订阅者 ----
function createComputed(fn) {
  const [get, set] = createSignal(); // 内部用一个信号承载结果
  createEffect(() => {
    set(fn());                      // effect 收集 fn 的依赖；依赖变则重算
  });
  return get;                       // 对外暴露只读的 get
}

// ---- 验证一下 ----
const [count, setCount] = createSignal(0);
const double = createComputed(() => count() * 2);

let renderCount = 0;
createEffect(() => {
  renderCount++;
  console.log(`count=${count()}, double=${double()}`);
});
// 输出：count=0, double=0   （首次执行）
//       count=1, double=2   （setCount(1) 后自动重算）
//       count=5, double=10  （setCount(5) 后自动重算）
setCount(1);
setCount(5);

这段 60 行代码的精髓在于 activeEffect 这个全局指针：effect 执行时把它自己挂上去，期间任何 read() 都会顺手把 effect 登记为订阅者。于是"谁读了信号"在运行时被自动记下来了——这就是细粒度响应式能实现 O(1) 精准更新的根本原因。

4.2 手写一个能跑的迷你虚拟DOM

再看 VDOM 派的核心：用 JS 对象描述 UI，靠 diff 算差异。

// mini-vdom.js —— 最小虚拟DOM：h 创建 + patch 打补丁（keyless 简化版）

// 用 mock DOM 方便在 Node 里跑，并统计"真实 DOM 写入次数"
function makeEl(tag) {
  return {
    tag,
    text: '',
    children: [],
    writes: 0,
    set textContent(v) { this.text = v; this.writes++; }, // 统计写入
    appendChild(c) { this.children.push(c); },
    replaceWith(n) { this._replaced = n; },
    addEventListener() {},
  };
}

// 创建虚拟节点
function h(tag, props, ...children) {
  return { tag, props: props || {}, children: children.flat() };
}

// 把虚拟节点变成真实 DOM
function createElement(vnode) {
  if (typeof vnode === 'string') {
    const t = makeEl('#text');
    t.textContent = vnode;
    return t;
  }
  const el = makeEl(vnode.tag);
  for (const [k, v] of Object.entries(vnode.props || {})) {
    if (k === 'onClick') el.addEventListener('click', v);
    else el[k] = v;
  }
  for (const child of vnode.children) el.appendChild(createElement(child));
  return el;
}

// 递归 diff + patch（简化的 keyless 算法）
function patch(el, oldV, newV) {
  if (oldV.tag !== newV.tag) {           // 标签都变了，整段替换
    el.replaceWith(createElement(newV));
    return;
  }
  // 更新属性
  for (const [k, v] of Object.entries(newV.props || {})) {
    if (k !== 'onClick') el[k] = v;
  }
  // 更新子节点：先对齐公共长度，再增删
  const oldCh = oldV.children, newCh = newV.children;
  const common = Math.min(oldCh.length, newCh.length);
  for (let i = 0; i < common; i++) {
    patch(el.children[i], oldCh[i], newCh[i]);
  }
  if (newCh.length > oldCh.length) {
    for (let i = common; i < newCh.length; i++) {
      el.appendChild(createElement(newCh[i]));
    }
  } else if (newCh.length < oldCh.length) {
    el.children.length = newCh.length; // 简化：截断
  }
}

// 渲染函数：每次都返回"完整的新树"
function renderList(items) {
  return h('ul', {},
    items.map((it) => h('li', { id: it.id }, it.text))
  );
}

// 首次渲染
let items = [{ id: 1, text: 'A' }, { id: 2, text: 'B' }, { id: 3, text: 'C' }];
const root = createElement(renderList(items));
console.log('首屏 DOM 写入次数:', root.writes);

// 更新：只把第 2 条改成 'B*'
// 注意：VDOM 是"重渲染整个组件"，所以我们要重新 render 整棵再 patch
items = [{ id: 1, text: 'A' }, { id: 2, text: 'B*' }, { id: 3, text: 'C' }];
const before = root.writes;
patch(root, renderList(items.slice(0, 0)), renderList(items)); // 简化示意
console.log('本次更新触发的 DOM 写入:', root.writes - before);

关键差异已经浮现：信号派更新第 2 条，只需改那一个 li 的 textContent（1 次写入）；VDOM 派即便只想改一条，也要重建整棵列表的 VNode 并做 diff。列表越长，这个差距越夸张。

4.3 同一个 Todo，三版对照（真实框架写法）

为了让你看到"同一份需求，三种思维"的具体代码差异，下面用三个真实框架写同一个"带计数的列表项"。

Vue Vapor（编译期直写）：

<script setup vapor>
import { ref } from 'vue'
const count = ref(0)
const items = ref(['理解信号', '手写响应式', '基准测试'])
</script>

<template>
  <p>已点击 {{ count }} 次</p>
  <ul>
    <li v-for="item in items" :key="item">{{ item }}</li>
  </ul>
  <button @click="count++">+1</button>
</template>

React + React Compiler（编译器优化 VDOM）：

// babel-plugin-react-compiler 自动插入 memo，你写裸代码
function Counter() {
  const [count, setCount] = useState(0);
  const items = ['理解信号', '手写响应式', '基准测试'];
  return (
    <div>
      <p>已点击 {count} 次</p>
      <ul>{items.map((it) => <li key={it}>{it}</li>)}</ul>
      <button onClick={() => setCount((c) => c + 1)}>+1</button>
    </div>
  );
}

Solid（信号派）：

import { createSignal, For } from 'solid-js';
function Counter() {
  const [count, setCount] = createSignal(0);
  const items = ['理解信号', '手写响应式', '基准测试'];
  return (
    <div>
      <p>已点击 {count()} 次</p>
      <ul><For each={items}>{(it) => <li>{it}</li>}</For></ul>
      <button onClick={() => setCount((c) => c + 1)}>+1</button>
    </div>
  );
}

三者的"开发者代码"几乎一样，但运行时天差地别：Vue Vapor 和 Solid 在 count 变化时只改那个 <p> 的 text；经典 React（无 Compiler）在 count 变化时会重跑 Counter 函数、重建所有 VNode 再 diff，而 React Compiler 会把"items 不变"这部分自动 memo 住，减少无谓重渲染，但本质上仍走 VDOM。

4.4 用信号驱动真实 DOM：从原理到落地

把 4.1 的信号系统和 4.2 的 mock DOM 接起来，你就拥有一个"无框架的 Vapor"：

// 用我们的 mini 响应式系统驱动一个真实（mock）DOM 文本节点
const [title, setTitle] = createSignal('初始标题');
const textEl = makeEl('span');
textEl.textContent = title(); // 首次

// 建立绑定：title 变 → 只更新这一个节点
createEffect(() => {
  textEl.textContent = title();
});

console.log(textEl.text); // "初始标题"
setTitle('后VDOM时代');
console.log(textEl.text); // "后VDOM时代" —— 只动了这一个节点

这就是 Vue Vapor 和 Solid 在底层真正做的事：把"状态→DOM 节点"的绑定编译成一个 effect。区别只是你手写还是编译器帮你写。

五、性能优化：用基准把复杂度摊开

5.1 基准方法论

我们设计一个可复现的基准：一个 10000 行的列表，每次只更新其中第 5000 行的内容。统计"真实 DOM 写入次数"和"耗时"。

// benchmark.js —— 对比"更新一万条里的某一条"
// 信号派：直接改那一个节点
function benchSignal(N) {
  const nodes = Array.from({ length: N }, () => makeEl('li'));
  const [target, setTarget] = createSignal('old');
  // 只把第 5000 个节点绑定到信号
  createEffect(() => { nodes[5000].textContent = target(); });
  const t0 = performance.now();
  for (let i = 0; i < 1000; i++) setTarget('new' + i); // 更新 1000 次
  const t1 = performance.now();
  return { writes: nodes[5000].writes, ms: t1 - t0 };
}

// VDOM 派：每次更新都重渲染整个列表再 patch
function benchVdom(N) {
  let list = Array.from({ length: N }, (_, i) => ({ id: i, text: 'old' }));
  const root = createElement(renderList(list));
  const t0 = performance.now();
  for (let i = 0; i < 1000; i++) {
    list[5000].text = 'new' + i;
    patch(root, /* old tree */ renderList(list), renderList(list));
  }
  const t1 = performance.now();
  return { writes: root.writes, ms: t1 - t0 };
}

（注：上面是示意，真实基准里 VDOM 的 patch 需要持有旧 VNode 引用；完整可运行版见文末仓库。）

5.2 结果解读（定性）

• 信号派：写入次数 = 1000（每次只动第 5000 行），耗时几乎不随 N 增长——O(1)。
• VDOM 派：每次都重建 10000 个 VNode 并 diff，写入/耗时随 N 线性增长——O(N)。当 N=10000，单次更新就要处理一万个节点对象，差距是数量级的。

重要的工程常识：O(1) 在常数很大时也可能输给 O(N) 在常数很小时。对于"一屏最多几十个节点的普通表单"，VDOM 完全够用，甚至因为实现成熟、调试友好而更省心。信号/编译直写的优势区间是大规模列表、实时数据流、协同编辑光标、可视化大屏这类"高频 + 局部"场景。

5.3 真实场景下的优化清单

不管你选哪条路，下面这些原则是共通的：

1. 批处理（Batching）：把同一 tick 内的多次状态变更合并成一次 DOM 提交。现代框架默认开启（Vue 的异步队列、React 18 的自动批处理、Solid 的 batch()）。手写信号系统时也要做：

// 手写批处理：同一微任务内的多次写入，只触发一次 effect
let pending = false;
let flushFns = [];
function batch(fn) {
  fn();
  if (!pending) {
    pending = true;
    queueMicrotask(() => {
      const fns = flushFns; flushFns = []; pending = false;
      fns.forEach((f) => f());
    });
  }
}

2. 别掉进"响应式地狱"：信号派最容易被坑的是"过度细分"——把本该一起变的状态拆成 100 个信号，导致 100 次独立 DOM 写入。该用 computed 聚合时就聚合。

3. 列表更新必须给 key：VDOM 和 For 都依赖稳定 key 来识别"这是同一条"还是"新增/删除"。没有 key，diff 会退化成位置对齐，出现错位 bug 和性能崩塌。

4. React Compiler 的陷阱：自动 memo 不是银弹。它优化的是"无谓重渲染"，但组件首次挂载、以及状态确实变化时的渲染成本一点没少。另外，ref 稳定性、useState 初始化函数的副作用、依赖全局可变变量等写法，仍可能让 Compiler 无从优化——该拆组件还是要拆。

5. 内存与 GC：VDOM 每次重渲染都产生大量短期 VNode 对象，对 GC 有压力；信号派持有的是"信号 → 订阅者"的图结构，长期驻留但体量小。两者 trade-off 不同，超大应用要实测。

六、总结展望：终局是分层，不是你死我活

6.1 三个判断

1. 虚拟DOM 不会消失，但会从"唯一真相"退居为"冷路径的默认选项"。声明式 UI 的开发体验太好，VDOM 在"低频、整页"更新上依旧舒适且足够快。
2. 信号会成为跨框架的底层共识。TC39 Signals 提案意味着"响应式原语"可能进入语言层，未来 Vue、Solid、Angular、Preact 的信号可能共享同一套语义——框架差异上移到"组件模型"和"编译策略"。
3. 编译期革命才刚开始。Vue Vapor、Svelte、React Compiler 都在证明一件事：把"怎么更新 DOM"从运行时搬到编译时，是确定性收益。2026 之后，"框架在编译期能做多少"将比"运行时多聪明"更决定性能。

6.2 给工程师的选型建议

6.3 写在最后

虚拟DOM 在过去十年是前端工程化的功臣，它用"声明式"解放了无数在 jQuery 里手写 diff 的开发者。但任何抽象都有代价，当状态规模、更新频率、交互密度都上了一个数量级，抽象本身的税就显形了。

2026 年的有趣之处不在于"谁打败了谁"，而在于两条原本对立的路径正在收敛到同一个认知：更新应该是精准的、编译期可预测的、运行时可追踪的。Vue 用 Vapor 把渲染编译掉，React 用 Compiler 把 memo 自动化，Solid 用信号把更新降到 O(1)——殊途同归。

作为写代码的人，最好的姿态不是站队，而是理解每条路径的复杂度曲线，然后把热路径交给信号、把冷路径交给声明式。当你下次写 setCount(c => c + 1) 时，脑子里能浮现出：这一行背后，是一个 effect 精准地、O(1) 地、只改了那一个文本节点——而不是重建了整个世界。

注：文中 Vue Vapor Mode、React Compiler 均指对应框架 2026 年公开的生产可用能力；基准为定性示意，完整可运行代码与精确数字见示例代码仓库。技术细节以各框架官方文档为准。