【深度图解】从 React、Vue 到 Signals：一文看懂前端三大 UI 更新机制的演进之路_signals 前端

前言

在现代前端开发中，我们追求的是声明式的、高效的 UI 构建方式。开发者只需关心“状态（State）”，而框架则负责将状态的变化智能地同步到用户界面（DOM）上。然而，不同的框架实现这一过程的底层机制却大相径庭，这直接决定了它们的性能和开发体验。

本文将通过详细的文字分析和清晰的流程图，带你深入对比当今最具代表性的三种 UI 更新机制：React 的虚拟DOM、Vue 的响应式虚拟DOM，以及被誉为未来的 Signals 细粒度更新。

为了方便理解，我们将使用一个统一的例子贯穿全文：一个父组件 App 包含 count 状态，并渲染两个子组件：一个显示 count 的 CounterDisplay，和一个不依赖 count 的 StaticComponent。当 count 值从 0 变为 1 时，UI 如何更新。

---

一、React: 自顶向下的虚拟DOM (Top-Down VDOM)

React 的核心理念是“UI 是状态的函数 (UI = f(state))”。当状态改变时，它会默认重新执行该组件及其所有子组件，然后通过对比找出最小变化。

核心步骤:

1. 触发 (Trigger): 在父组件 App 中调用 setState({ count: 1 })。
2. 调度与渲染 (Schedule & Render): React 将更新放入队列，并由调度器触发 Render 阶段。此阶段会从根组件开始，自顶向下重新执行整个组件子树（包括 App, CounterDisplay 和 StaticComponent），生成一颗全新的虚拟DOM树。
3. 比对 (Reconciliation/Diffing): 在 Commit 阶段，React 会拿出新、旧两个虚拟DOM树进行比较。
4. 打补丁 (Patch): Diff 算法计算出最小变更集（只有 CounterDisplay 中的文本节点需要从 ‘0’ 变为 ‘1’），然后只把这个变更应用到真实的浏览器DOM上。

比喻: 就像为了修改一个房间的墙壁颜色，你选择重新绘制一整张包含所有房间的建筑蓝图，然后和旧蓝图对比，找出墙壁颜色的变化，最后只派工人去粉刷那一面墙。重点在于“重新画整张蓝图”这个步骤，它覆盖了所有房间，即使很多房间根本不需要改动。

流程图 (内部机制):

---

二、Vue: 响应式驱动的虚拟DOM (Reactivity-driven VDOM)

Vue 通过其强大的响应式系统，可以精确地知道“哪个组件”依赖了“哪个数据”，从而只更新真正需要更新的组件，避免了不必要的重渲染。

核心步骤:

1. 依赖收集 (Dependency Tracking): 首次渲染时，CounterDisplay 的 render 函数执行，读取了 count.value。Proxy 的 get Trap被触发，调用 track() 函数，将 count 属性和 CounterDisplay 的渲染 Effect 绑定起来，存入一个全局的依赖地图。
2. 触发 (Trigger): 当代码执行 count.value = 1 时，Proxy 的 set Trap被触发。
3. 精确通知 (Notify): set Trap调用 trigger() 函数，从依赖地图中找到所有依赖 count 的 Effect（这里只有 CounterDisplay 的），并将它们放入调度器准备执行。完全无关的 StaticComponent 不会被通知。
4. 渲染与比对 (Render & Diff): 只有 CounterDisplay 组件的 Effect (即其渲染函数)被重新执行，生成新的虚拟DOM，然后进行 Diff 和 Patch。

比喻: 就像一个智能的图书馆管理员，他知道 CounterDisplay 借了 count 这本书。当这本书有了新版本时，管理员会直接查阅借阅记录，精准地只通知 CounterDisplay，而完全不会去打扰对这本书不感兴趣的 StaticComponent。

流程图 (内部机制):

---

三、Signals: 精准的细粒度更新 (Fine-Grained Reactivity)

Signals 范式被认为是响应式编程的未来。它完全抛弃了虚拟DOM，建立了从“数据”到“DOM更新操作”的直接、精准的链接。其内部机制如下图所示，核心是 Signal（信号）和 Effect（副作用）两个概念。

流程图 (内部机制):

核心步骤:

1. 依赖收集 (Read & Subscribe):

   • 当一个 Effect (例如，一个更新DOM的函数) 首次执行时，它会读取（Read）一个或多个 Signal 的 Value。
   • Signal 的 Read 操作会检测到当前正在执行的 Effect (通过一个全局的 Active Observer)，并将其作为 Subscriber (订阅者) 保存起来。
   • 同时，Effect 也会将这个 Signal 记录到自己的 Subscriptions (订阅列表) 中。这是一个双向链接的过程。

2. 触发 (Write & Notify):

   • 当代码通过 Write 操作 (例如 count.set(1)) 更新 Signal 的 Value 时。
   • Write 操作会遍历其内部的 Subscribers 列表，并调用 Notify，通知每一个订阅它的 Effect。

3. 直接执行 (Execute):

   • 被通知的 Effect 会重新执行其 Callback 函数。
   • 在执行前，它会先 Clean up (清理) 自己旧的订阅关系，以确保依赖关系总是最新的。
   • Callback 函数直接操作真实DOM，将文本内容从 ‘0’ 改为 ‘1’。这个过程完全没有虚拟DOM，没有Diff/Patch，实现了极致的性能。

比喻: 这就像一个直连的电路。Signal 是一个带有记忆和订阅者列表的开关，Effect 是连接到灯泡的电路。当你按下开关 (Write)，电流 (Notify) 只会沿着之前铺设好的线路 (Subscribers)，直接点亮那盏特定的灯泡 (Execute Effect)。

---

历史的十字路口：为什么首先是 VDOM，而不是 Signal？

这是一个深刻的问题，答案在于思想范式、技术局限和当时要解决的核心痛点这三个方面。简单来说，并不是“没想到”，而是 VDOM 和 Signal 代表了两种从根本上不同的解决问题的哲学，在当时的历史背景下，VDOM 的哲学更具革命性和吸引力。

1. 核心思想的差异：函数式 vs 响应式

• React (VDOM) 的诞生是对“状态管理混乱”的回应，其武器是函数式编程思想。

  • 在 React 之前，开发者通常使用命令式的代码（如 jQuery）手动操作 DOM，代码逻辑很快会变得混乱且难以维护。
  • React 带来了 UI = f(state) 的声明式理念。在这个模型里，组件就是函数，当状态改变时，最简单、最可靠的方式就是重新执行整个函数，得到一个全新的 UI 描述。虚拟 DOM 就是为了让这个“粗暴”但纯粹的模型在浏览器中变得足够高效而发明的配套技术。它提供了一种更可预测、更明确的数据流（自顶向下），在当时被视为对“魔法般”的响应式系统的一种改进。

• Signal 的思想源于更经典的“响应式编程”。

  • 这种思想就像电子表格：当单元格 A1 的值改变时，任何依赖于 A1 的公式都会自动更新。像 Knockout.js 等早期框架就已经实现了类似机制。
  • 然而，在当时，这种“自动”更新的机制被很多人认为是“魔法”，因为依赖关系是隐式追踪的，当应用变复杂时，可能难以搞清楚一个状态的改变到底会触发链条上的哪些反应，调试起来相对困难。

2. JavaScript 语言能力的限制

现代 Signal 系统的优雅实现，在很大程度上依赖于 ES6 (2015) 引入的 Proxy。

• 早期 (React 诞生时 ~ 2013年): 当时的 JavaScript (ES5) 没有 Proxy。要实现响应式，主要靠 Object.defineProperty()，但它无法完美地监听所有对象变化（如新增属性、数组索引），需要额外的 API 来弥补，实现起来更复杂。
• 现代 (Signal 流行时): Proxy 可以在一个对象上设置一个“代理”，从而拦截所有类型的操作，这使得创建真正透明且功能完备的响应式系统变得前所未有的简单和高效。

3. 解决的首要问题不同

• React 的首要目标是提供一个更好的应用架构。 它的核心创新是组件化——将 UI 拆分成独立的、可复用的部分。VDOM 是服务于这个组件化模型的引擎。
• Signal 的首要目标是极致的运行时性能。 它是对“更新过程”的优化，力求消除一切不必要的操作。

可以认为，React 首先解决了“如何组织代码”的宏观问题，而 Signal 则是在此基础上，利用现代 JavaScript 的能力，进一步解决了“如何让更新更高效”的微观问题。VDOM 在当时是一个“天时、地利、人和”的产物，而 Signal 则是站在 VDOM 所建立的“组件化”巨人肩膀上的再一次进化。

---

附录：什么是 Proxy？现代响应式的基石

Proxy 是理解现代 Vue 和 Signals 如何实现高效响应式的关键。简单来说，Proxy 是 JavaScript (ES6) 提供的一个元编程特性，它允许你创建一个对象的“代理”，从而拦截并自定义在该对象上的各种基础操作。

生活化的比喻：大楼的“前台”

想象一下，有一个普通的目标对象 target，它就像一栋大楼。

• 没有 Proxy：你可以直接走到大楼的任何一个房间（即访问对象的任何属性），比如 target.roomA。
• 有了 Proxy：你在大楼门口设置了一个前台（Proxy）。现在，任何人想进入大楼找房间（读取属性），或者想给某个房间送东西（设置属性），都必须先经过前台。

这个“前台”可以做很多事情：

• 拦截读取 (get)：当有人想访问 roomA 时，前台可以先记录下“某某某正在访问 roomA”（依赖收集/track），然后再放他进去。
• 拦截写入 (set)：当有人想修改 roomA 的状态时，前台可以先进行检查，更新状态后，还可以通知所有关心 roomA 的人：“roomA 刚刚变了！”（触发更新/trigger）。

Proxy 就是这个前台，它让你有机会在外部对一个对象进行访问或修改时，执行一些额外的逻辑，而不需要改变那个对象本身。

“陷阱”机制的可视化

为了更清晰地理解这种拦截机制，我们可以通过下面这张图来看看当执行 userProxy.name (读取) 和 userProxy.age = 31 (写入) 时，发生了什么。

这张图清晰地展示了：

1. 所有对 proxy 对象的访问，都必须先经过 Proxy 拦截层。
2. 不同的操作会“掉入”不同的陷阱（get 或 set）。
3. 在陷阱内部，我们有机会在操作到达原始对象之前执行自定义的逻辑（如依赖收集、触发更新）。
4. 陷阱最终决定是将操作放行到原始对象，还是执行其他行为。

这个“陷阱”机制是 Proxy 功能强大且灵活的根源。

代码示例

// 1. 目标对象 (我们的“大楼”)const user = { name: \"Alice\", age: 30};// 2. 定义拦截规则 (我们的“前台”)const handler = { // 当读取属性时触发 get(target, property) { console.log(`依赖收集：正在读取 \'${property}\' 属性...`); return target[property]; // 返回原始值 }, // 当设置属性时触发 set(target, property, value) { console.log(`触发更新：正在设置 \'${property}\' 属性，新值为: ${value}`); target[property] = value; // 设置原始值 console.log(\"--- 属性已更新，通知所有订阅者！---\"); return true; // 表示设置成功 }};// 3. 创建代理对象const userProxy = new Proxy(user, handler);// --- 现在，我们所有操作都通过代理来进行 ---// 读取操作被 get Trap拦截console.log(userProxy.name); // 输出:// 依赖收集：正在读取 \'name\' 属性...// Alice// 写入操作被 set Trap拦截userProxy.age = 31;// 输出:// 触发更新：正在设置 \'age\' 属性，新值为: 31// --- 属性已更新，通知所有订阅者！---

为什么 Proxy 是“游戏规则改变者”？

在 Proxy 出现之前 (ES5 时代)，Vue 2 等框架使用的是 Object.defineProperty()。它也能实现类似的功能，但有几个致命缺陷：

• 无法监听新增/删除属性：如果给 user 对象新增一个 gender 属性，Object.defineProperty 监听不到。
• 无法直接监听数组索引和长度的变化：对于数组的很多操作，它都无能为力。
• 需要特殊 API：因此，Vue 2 必须提供像 Vue.set 和 Vue.delete 这样的特殊 API 来弥补这些缺陷。

Proxy 解决了所有这些痛点，它可以全面拦截多达 13 种不同的操作，无论是新增属性、删除属性还是修改数组，都能完美捕获，且开发者无需使用任何特殊 API。

这就是为什么 Vue 3 和所有基于 Signal 的现代库都把 Proxy 作为其响应式系统的核心。它为框架提供了一个强大、全面且透明的工具，去精准地监听数据的一切变化。

深度解析：Proxy vs Object.defineProperty

为了更深入地理解两者的差异，我们来看看它们在“设计哲学”和“实现能力”上的根本不同。

1. Proxy: 引擎层面的“代理”

Proxy 并不是用 JavaScript 代码实现的，它是 JavaScript 引擎（如 V8、SpiderMonkey）的原生功能，通常由 C++ 实现。它在语言的底层创建了一个真正的“拦截层”。

• 工作模式: new Proxy(target, handler) 创建一个全新的“代理”对象。所有对该代理对象的操作（读取、赋值、删除、函数调用等）都会被引擎拦截，然后引擎会去调用你在 handler 中定义的相应方法（如 get, set, deleteProperty）。
• 设计哲学: 代理整个对象。它像一个无所不知的“前台”，任何对大楼（对象）的访问请求都必须先经过它。因此，它能感知到所有类型的变化，包括新增属性、删除属性等。
• 能力: 全面、强大。它代理的是对象本身，而非对象的属性。

2. Object.defineProperty: 对象属性的“描述符”

Object.defineProperty 是 ES5 提供的 API，它的设计初衷是用来精确地定义或修改对象上某个特定属性的特性（如是否可写、是否可枚举），重写 getter 和 setter 只是其能力之一。

• 工作模式: Object.defineProperty(obj, prop, descriptor) 直接在原始对象 obj 上操作，修改 prop 这个指定属性的行为。它需要遍历对象的所有现有属性，并为每个属性单独设置 getter/setter。
• 设计哲学: 修改单个属性。它像一个只负责特定房间（属性）的“保安”。你无法让它知道大楼里新建了房间（新增属性），或者拆除了房间（删除属性）。
• 能力: 有限、有针对性。它的“缺陷”是其设计的必然结果，无法被“修复”，只能通过 Vue.set 这样的辅助函数来“绕过”。

特性对比 Proxy (ES6) Object.defineProperty (ES5) 监听范围 整个对象 单个属性 新增属性 ✅ 直接监听 ❌ 无法监听，需用 Vue.set 删除属性 ✅ 直接监听 ❌ 无法监听，需用 Vue.delete 数组操作 ✅ 完美监听 (包括索引、push, length 等) ❌ 对 push 等方法无能为力，需重写数组原型 实现方式 引擎原生支持，性能更好，创建一个新代理对象 递归遍历所有属性，修改原对象，可能较慢 API 简洁性 无需额外 API，操作自然 需 Vue.set/delete 等特殊 API

结论很明确：Proxy 在响应式系统实现上是 Object.defineProperty 的一次彻底的、根本性的升级。它不是对旧方案的简单改进，而是一种在语言层面提供的、更强大、更符合直觉的全新范式，使得现代响应式框架的实现变得前所未有的优雅和高效。

---

总结与对比

React

• 核心思想: UI是状态的函数
• 更新范围: 组件级别 (自顶向下，默认更新整个子树)
• 关键技术: 虚拟DOM
• 性能开销: 组件重渲染 (可能包含非必要组件) + VDOM Diff
• 心智模型: 每次都重新构建，简单但有浪费
• 发展趋势: 成熟稳定，生态庞大

Vue

• 核心思想: 响应式数据驱动视图
• 更新范围: 组件级别 (精准触发，只更新相关组件)
• 关键技术: Proxy + 虚拟DOM
• 性能开销: 组件重渲染 (更少) + VDOM Diff
• 心智模型: 自动追踪，智能但有魔法感
• 发展趋势: 性能与开发的完美平衡

Signals

• 核心思想: 响应式数据图直接更新DOM
• 更新范围: 数据绑定级别 (精准到DOM节点)
• 关键技术: 响应式图 (Reactivity Graph)
• 性能开销: 几乎为零，无VDOM开销
• 心智模型: 逻辑直连，简单且高效
• 发展趋势: 未来方向，追求极致性能

结论

从 React 的虚拟DOM，到 Vue 的响应式优化，再到 Signals 的无虚拟DOM的细粒度更新，我们看到了一条清晰的技术演进路线：不断减少不必要的计算和操作，追求最精准、最高效的 UI 更新。

虽然虚拟DOM在过去十年中极大地推动了前端开发的发展，但 Signals 所代表的细粒度响应式模型，凭借其卓越的性能和简洁的心智模型，正被越来越多的现代框架（如 SolidJS, Qwik, Preact, Vue）所采纳，无疑是未来前端性能优化的一个关键方向。理解它们的差异，将帮助我们更好地选择技术栈，并写出更高性能的应用程序。