讲座主题：React 的“蓝图”与 Signals 的“通知”——一场关于 UI 渲染的终极辩论
各位前端工程师、架构师，以及那些在 useEffect 里把自己绕晕的朋友们，大家好！
今天我们不聊 API，不聊 CSS 框架，我们聊聊 UI 的“灵魂”。我们要探讨一个困扰了前端社区十几年的终极问题：我们到底该怎么告诉浏览器“更新一下”这个界面？
是像 React 那样，每次都把整个世界重新画一遍，然后用数学算法找出哪里变了？还是像那些新兴的信号库那样，盯着你的数据，谁变了谁通知，谁也不打扰谁？
这不仅仅是选哪个库的问题，这是两种编程哲学的碰撞。来，搬好小板凳，我们把咖啡倒上，咱们开聊。
第一部分：React 的“老派绅士”作风——虚拟 DOM
首先，让我们回到 2013 年。那时候 React 刚刚横空出世，Jeffrey 说了那句名言：“一切都应该是一个组件。” 但是，React 的作者们当时面临一个巨大的难题：HTML 是命令式的（你告诉它怎么画），JavaScript 是声明式的（你告诉它你想要什么）。 这就像你跟一个只会听指令的哑巴画师说“给我画个苹果”，但他听不懂，你得把画笔塞进他手里，手把手地画。
React 的解决思路非常“老派绅士”：全量渲染，局部优化。
1. 虚拟 DOM：那个看不见的“蓝图”
React 的核心概念叫 Virtual DOM。听名字很高大上，其实它就是一个普通的 JavaScript 对象。
当你写：
function App() {
return <h1>Hello, World!</h1>;
}React 不会直接去改浏览器里的 DOM。它会先在内存里造一个对象：
const virtualDOM = {
type: 'h1',
props: { children: 'Hello, World!' }
};这个对象就像是一张“蓝图”。React 每次状态变化，就会生成一张新的“蓝图”，然后拿着两张蓝图（旧蓝图 vs 新蓝图）去对比。
2. Diff 算法：地毯式搜索的艺术
React 的核心引擎就是 Diff 算法。它的目标是在庞大的 DOM 树中，找到那个“唯一”的变动点。
React 的 Diff 算法有三条铁律，这简直是把计算机科学玩到了极致：
- 同层比较：React 不会跨层级比较。比如
<div>里的<span>变成了<p>，React 不会尝试去修改<span>的属性让它变成<p>，而是直接把<div>里的<span>整个干掉，在下面挂一个新的<p>。这就像装修房子，你不能把马桶改造成沙发，你得把马桶砸了，再搬个沙发进来。 - 类型优先：如果节点类型变了（比如从
div变成了span），React 认为这是完全不同的节点，直接重建。 - Key 是灵魂：这是 React 开发者的噩梦，也是 React 的救命稻草。如果你在列表里不加
key，React 就会傻傻地对比每一个子节点。比如你把列表里的第一个元素删了，React 会发现：诶？旧的第一个是 A，新的第一个是 B。React 会认为这是同一个节点 A 发生了变异，于是它去修改 A 的属性。结果？你的界面闪烁了，或者数据错乱了。
代码示例：React 的渲染过程
import React, { useState } from 'react';
function Counter() {
const [count, setCount] = useState(0);
const [text, setText] = useState('Initial');
// 这里的 render 每次都会执行
return (
<div>
<h1>Count: {count}</h1>
<p>Text: {text}</p>
<button onClick={() => setCount(c => c + 1)}>Add</button>
<button onClick={() => setText('Updated')}>Change Text</button>
</div>
);
}当你点击“Add”按钮时，React 做了什么？
- 调用 render：
Counter组件的函数重新执行了一遍。整个 JSX 被重新计算，生成了一个新的 Virtual DOM 树。 - Diff 对比：React 拿着旧的树和新的树进行对比。
div对div：类型没变，保留。h1对h1：类型没变，保留。text变了？React 发现 props 变了。
- Reconciliation（协调）：React 发现
count变了，它不会直接去改 DOM 里的文本节点，而是标记这个节点为“dirty”，然后等下一帧再统一修改。
React 的优点：它把“如何高效地操作 DOM”这个复杂的难题封装了起来。你不需要关心浏览器底层，你只需要声明式地描述 UI。对于大型应用来说，这种一致性保证了 UI 和数据永远同步。
React 的缺点：它是“粗粒度”的。只要 count 变了，React 就得重新跑一遍整个组件树的 Diff 算法。哪怕你的组件树有 100 层，只有最顶层的 h1 变了，React 也会把下面 99 层的组件重新计算一遍。
第二部分：Signals 的“新派黑客”作风——细粒度响应式
那么，有没有一种方法，能让你只改一个数字，浏览器只更新那个数字呢？有，这就是 Signals（信号），以及基于它构建的框架（比如 Preact Signals, Vue 3 的响应式系统，或者 SolidJS）。
Signals 的哲学完全不同。它抛弃了“全量渲染”，拥抱了“数据驱动视图”。
1. 核心概念：监听器
想象一下，你的数据就像是一个房间里的温度计。Signals 就是一个智能传感器。当温度计的数字变了，传感器立刻向房间里的所有收音机发送一条信息：“嘿，温度变了！”
在代码里，这叫 依赖收集。
2. Proxy：现代 JavaScript 的魔法
Signals 是如何知道数据变了？靠的是 Proxy 对象。Proxy 可以拦截对象的读取和修改操作。
当你创建一个 Signal 时，你其实是在创建一个 Proxy。
// 伪代码演示
let count = 0;
const countSignal = new Proxy(count, {
get(target, prop) {
// 当有人读取 countSignal.count 时
return target[prop];
},
set(target, prop, value) {
// 当有人修改 countSignal.count 时
if (target[prop] !== value) {
target[prop] = value;
// 关键步骤：通知所有订阅了这个信号的人！
notifySubscribers(countSignal);
}
return true;
}
});3. 细粒度更新：只改我需要的
Signals 的渲染机制非常激进。它没有 render() 函数，它只有 effect()（副作用）。
当你写代码：
const count = signal(0);
const text = signal('Hello');
// 这是一个 Effect
effect(() => {
console.log(count()); // 这里读取了 count
console.log(text()); // 这里读取了 text
});当 count 变了，只有那个 Effect 会重新执行。如果代码里没有读取 count，React 就算把整个宇宙都改了，这个 Effect 也不会动一下。
代码示例：Signals 的实现
// 模拟一个简单的信号系统
class Signal {
constructor(value) {
this._value = value;
this._subscribers = new Set();
}
get value() {
// 读取时，把自己注册到当前正在运行的 Effect 中
if (activeEffect) {
activeEffect._dependencies.add(this);
}
return this._value;
}
set value(newValue) {
if (this._value !== newValue) {
this._value = newValue;
// 修改时，通知所有订阅者
this._subscribers.forEach(fn => fn(this._value));
}
}
}
// 模拟 Effect 系统
let activeEffect = null;
function effect(fn) {
activeEffect = {
fn: fn,
_dependencies: new Set()
};
fn(); // 执行副作用
activeEffect = null;
}
// --- 使用场景 ---
const count = new Signal(0);
const doubleCount = new Signal(0); // 我们假设这个值由 count 决定
effect(() => {
// 假设这是一个 DOM 更新操作
document.getElementById('app').innerText = `Count: ${count.value}`;
console.log("Effect 执行了！当前值:", count.value);
});
// 改变 count
count.value = 1;
// 输出：Effect 执行了！当前值: 1
// 再改一次
count.value = 2;
// 输出：Effect 执行了！当前值: 2你看，这个流程多干净。没有 Virtual DOM，没有 Diff 算法，没有 Fiber 树。只有数据流动。
第三部分：React vs Signals——架构深度的交锋
好了，我们聊了两种路径。现在我们来点硬核的。为什么 React 不直接用 Signals？为什么 Signals 没有取代 React？
1. 不可变数据 vs 可变数据
这是最大的分歧点。
React 是一个不可变数据的狂热信徒。
// React 风格
const [count, setCount] = useState(0);
setCount(count + 1); // 你不能直接 count++，因为 count 是个不可变对象不可变数据的好处是“时间旅行调试”和“Diff 算法”。因为数据不可变，所以很容易生成一个新的状态树，然后跟旧的树比一比。这种模式非常适合复杂的状态管理，比如 Redux。
Signals 是可变数据的拥护者。
// Signals 风格
let count = signal(0);
count.value++; // 简单，直接，像写原生 JS 一样舒服可变数据更符合人类的直觉。你不需要记住 prevCount，你只需要知道 currentCount。
2. 副作用管理：useEffect vs on
React 有一个著名的痛点：useEffect 的依赖数组。
useEffect(() => {
// 这是一个副作用
console.log(count);
}, [count]); // 你必须手动告诉 React 什么时候重新执行如果你忘了写 [count]，React 就会在下一次渲染时再次运行这个 Effect，导致无限循环或者内存泄漏。
Signals 使用 on 函数来处理副作用，它更聪明。
const count = signal(0);
on(count, (newVal) => {
// 当 count 变化时，自动执行，不需要依赖数组
console.log("Count changed to", newVal);
});Signals 的系统会自动追踪你在 Effect 里读到了哪些数据，一旦这些数据变了，Effect 自动触发。这叫 自动依赖收集。这简直是懒人的福音。
3. 虚拟 DOM 的真正价值：Hydration（水合）
很多人诟病 React 的 Virtual DOM 慢。但在 SSR（服务端渲染）时代，Virtual DOM 是神。
假设你在服务端渲染了一个 HTML 页面：
<!-- Server Rendered HTML -->
<div id="root">Hello, World!</div>当这个页面加载到浏览器时，React 需要把这个 HTML 转换成 Virtual DOM。
// React 的 Hydration
const virtualDOM = {
type: 'div',
props: { children: 'Hello, World!' }
};然后 React 会拿着这个 Virtual DOM 和浏览器里的真实 DOM 对比。
- 如果一致，OK，继续。
- 如果不一致（比如服务端渲染了 5，浏览器状态是 0），React 会把那个节点替换掉。
Signals 做不了这个。因为 Signals 的核心是“可变”，而服务端渲染的是“静态 HTML”。Signals 需要在加载后“冻结”它的状态，这非常尴尬。所以，Signals 生态目前主要集中在客户端。
4. 并发模式：React 的反击
React 18 引入了 Concurrent Mode（并发模式）。这是 React 团队试图模仿 Signals 的一次尝试。
React 现在引入了 startTransition。它的意思是：“嘿，渲染器，别急着把那个按钮画出来，先渲染一下列表，如果用户点得快，就取消那个按钮的渲染。”
这其实就是在试图实现“细粒度更新”的体验。React 试图在不改变其 Virtual DOM 架构的前提下，通过“调度”和“优先级”来优化渲染。
但是，React 的架构太重了。要实现真正的并发，React 必须把组件拆解成无数个微小的 Fiber 节点。这导致了代码的复杂度呈指数级上升。而 Signals 原生就是细粒度的，它天生就支持并发，因为它的更新是独立的。
第四部分：实战演练——重构一个购物车
为了让大家更直观地感受区别，我们写一个简单的购物车。
场景：商品列表，点击购买，数量 +1，总价更新。
1. React 版本
import React, { useState } from 'react';
function ShoppingCart() {
// 状态管理：商品列表
const [products, setProducts] = useState([
{ id: 1, name: 'iPhone', price: 5999 },
{ id: 2, name: 'MacBook', price: 9999 },
]);
// 状态管理：购物车（假设购物车也是一个数组）
const [cart, setCart] = useState([]);
const addToCart = (productId) => {
// 1. 找到商品
const product = products.find(p => p.id === productId);
// 2. 检查购物车里有没有这个商品
const existingItem = cart.find(item => item.id === productId);
if (existingItem) {
// 3. 如果有，数量 +1 (这里 React 要求不可变更新)
setCart(cart.map(item =>
item.id === productId ? { ...item, quantity: item.quantity + 1 } : item
));
} else {
// 4. 如果没有，push 进去
setCart([...cart, { ...product, quantity: 1 }]);
}
};
// 计算总价：每次渲染都要重新计算
const total = cart.reduce((sum, item) => sum + (item.price * item.quantity), 0);
return (
<div>
<h2>商品列表</h2>
<ul>
{products.map(p => (
<li key={p.id}>
{p.name} - ¥{p.price}
<button onClick={() => addToCart(p.id)}>加入购物车</button>
</li>
))}
</ul>
<h2>购物车</h2>
<ul>
{cart.map(item => (
<li key={item.id}>
{item.name} x {item.quantity}
</li>
))}
</ul>
<h3>总价: ¥{total}</h3>
</div>
);
}React 的思考过程：
当你点击“加入购物车”时，addToCart 执行。
React 触发一次重新渲染。
它重新计算 products.map（虽然没变），重新计算 cart.map（变了），重新计算 total（变了）。
它生成一个新的 Virtual DOM，Diff，然后更新 DOM。
2. Signals 版本 (Preact Signals 风格)
import { signal, computed, effect } from 'preact signals';
// 1. 定义状态（可变！）
const products = signal([
{ id: 1, name: 'iPhone', price: 5999 },
{ id: 2, name: 'MacBook', price: 9999 },
]);
const cart = signal([]);
// 2. 定义计算属性（自动缓存）
const total = computed(() => {
console.log("计算总价中...");
return cart.value.reduce((sum, item) => sum + (item.price * item.quantity), 0);
});
// 3. 定义副作用（UI 更新）
effect(() => {
console.log("渲染 UI...");
// 渲染商品列表
const listHtml = products.value.map(p => `
<li>
${p.name} - ¥${p.price}
<button onclick="addToCart(${p.id})">加入购物车</button>
</li>
`).join('');
// 渲染购物车
const cartHtml = cart.value.map(item => `
<li>${item.name} x ${item.quantity}</li>
`).join('');
// 更新 DOM (这里简化了，实际框架会做 Diff)
document.getElementById('app').innerHTML = `
<div>
<h2>商品列表</h2>
<ul>${listHtml}</ul>
<h2>购物车</h2>
<ul>${cartHtml}</ul>
<h3>总价: ¥${total.value}</h3>
</div>
`;
});
// 4. 交互逻辑
window.addToCart = (id) => {
const product = products.value.find(p => p.id === id);
const existingItem = cart.value.find(item => item.id === id);
if (existingItem) {
existingItem.quantity++; // 直接修改，爽！
} else {
cart.value = [...cart.value, { ...product, quantity: 1 }];
}
};Signals 的思考过程：
当你点击“加入购物车”时，addToCart 执行。
existingItem.quantity++ 执行。
cart.value 变了。
触发计算属性 total 的重新计算。注意，只有 total 依赖了 cart，所以它才计算。其他不依赖 cart 的变量（比如 products）完全没反应。
触发 effect。Effect 重新运行，生成 HTML，更新 DOM。
对比结果：
React 就像是一个严谨的会计，每一笔账都要重新算一遍，还要打印出详细的凭证（Diff 算法）。
Signals 就像是一个精明的销售，手里拿着账本，谁买了东西，他就把那个数字改一下，然后抬头看一眼总价，如果变了就喊一声“新价格出来了！”。至于昨天卖了多少，他根本不在乎。
第五部分：React 的“变心”——React Compiler 与未来的融合
说了这么多 Signals 的好，React 也不甘示弱。最近，React 团队提出了 React Compiler（编译器）。
这是什么意思？React 以前是“运行时”优化。你在写代码时，必须手写 useMemo、useCallback 来告诉 React 哪些东西是稳定的。
React Compiler 的出现，意味着：编译器会自动帮你做这些事。
编译器会分析你的代码，如果发现某个变量没有被修改过，它就会自动把它标记为“纯函数”的输入。这样，React 就可以放心地跳过这个组件的渲染，因为它知道结果不会变。
这实际上是在向 Signals 的“细粒度”靠拢。React 想要实现：不依赖任何魔法，仅仅通过静态分析，就能达到细粒度更新的性能。
这是一个非常激进的尝试。如果成功，React 就不需要再纠结于 Fiber 树的复杂度了，它可以直接在编译阶段就锁定哪些组件需要更新。
第六部分：到底该选哪个？
作为专家，我不能给你一个绝对的答案。这取决于你的需求。
选择 React，如果：
- 你需要 SSR（服务端渲染）。
- 你需要维护一个非常庞大的、历史悠久的团队项目。
- 你喜欢不可变数据带来的状态可预测性。
- 你喜欢“声明式 UI”带来的开发快感，哪怕它有时候会慢一点。
选择 Signals (或类似的细粒度框架)，如果：
- 你在写纯前端应用（SPA），不需要 SSR。
- 你讨厌
useEffect的依赖数组地狱。 - 你觉得写
setState(prev => prev + 1)很繁琐，想直接count++。 - 你追求极致的性能，你的应用里有非常复杂的交互（比如大型表格、绘图板）。
结语：没有银弹
其实，不管是 Virtual DOM 还是 Signals，它们都是工具，都是为了让“数据”和“视图”保持同步。
Virtual DOM 是一种妥协的艺术，它在“开发体验”和“运行时性能”之间找了个平衡点。
Signals 是一种激进的技术，它直接利用了现代 JavaScript 的 Proxy 特性，追求极致的性能和代码的可读性。
React 正在进化，它试图吸收 Signals 的优点（细粒度更新），而 Signals 也在变得越来越像 React（引入了 Suspense，引入了组件化）。
作为开发者，我们不应该被框架的名字束缚。当你理解了它们底层的逻辑——Diff 算法也好，依赖收集也好，响应式也好——你就掌握了 UI 开发的核心。
下次当你看到 setState 触发了一次不必要的重渲染时，你不会只怪 React 慢，你会知道，哦，原来是因为我在那个不可变的对象里做了一些多余的操作。
好了，今天的讲座就到这里。记住，代码是写给机器看的，但架构是写给人类看的。理解了原理，你才是真正的架构师。
谢谢大家！