写在前面
React 的痛： 在 React 中，一个 State 变了，组件就会重新执行（Re-render）。为了性能，我们不得不搞出 Fiber 架构，搞出时间切片，搞出
useMemo。这就好比：为了能在干草堆里找到一根针，React 发明了一台超级高科技的“干草堆翻找机”。Signal 的解： 细粒度响应式（Signal）的思路是：在扔针进去的时候，就给针系上一根绳子。要找针的时候，拉绳子就行了。
本篇我们将深入内核，手写一个迷你 Signal 系统，看清它的本质。
一、 宏观对决：VDOM vs. Fine-Grained (细粒度)
要理解 Signal，首先要理解它想革谁的命。
1.1 VDOM 的“地毯式搜索”
React 的更新模型是 Snapshot（快照） 式的。
- 流程： 数据变了 -> 运行整个组件函数 -> 生成新的 VDOM 树 -> 对比新旧树 (Diff) -> 找出差异 -> 更新 DOM。
- 复杂度： 跟组件树的大小成正比。
- 问题： 哪怕只改了一个文本节点，整个组件（甚至子组件）的逻辑都要重跑一遍。
1.2 Signal 的“点对点狙击”
SolidJS 或 Vue 的更新模型是 Dependency Graph（依赖图） 式的。
- 流程： 数据变了 -> 直接定位到绑定了该数据的 DOM 节点 -> 更新 DOM。
- 复杂度： 跟动态节点的数量成正比（通常是 O(1)）。
- 核心： 组件函数只在初始化时运行一次！之后再也不会运行了。
二、 解剖 Signal：发布订阅的进化体
Signal 并不神秘，它本质上就是 “保存值的容器” + “自动依赖追踪” 。 它由两个核心动作组成：Track (追踪/读) 和 Trigger (触发/写) 。
2.1 核心 API 模拟
以 SolidJS/React 风格为例，我们造一个 Signal：
// 这是一个全局变量，用来记录“当前谁在查我不？”
let activeEffect = null;
function createSignal(initialValue) {
let value = initialValue;
const subscribers = new Set(); // 订阅者名单
// Getter (读)
const read = () => {
if (activeEffect) {
// 1. 依赖收集 (Track)：如果有人在关注我，把他记下来
subscribers.add(activeEffect);
}
return value;
};
// Setter (写)
const write = (newValue) => {
value = newValue;
// 2. 派发更新 (Trigger)：通知名单里所有人干活
subscribers.forEach(fn => fn());
};
return [read, write];
}
2.2 魔法的粘合剂：Effect
光有 Signal 没用，得有人“读”它，订阅关系才能建立。这就需要 createEffect（在 Vue 里叫 watchEffect）。
function createEffect(fn) {
// 把自己标记为“正在执行的副作用”
activeEffect = fn;
// 执行一次函数。
// 注意：函数内部会读取 Signal，从而触发 Signal 的 Getter，
// 进而把这个 fn 添加到 subscribers 里。
fn();
// 执行完复原
activeEffect = null;
}
2.3 跑起来看看
const [count, setCount] = createSignal(0);
createEffect(() => {
console.log("数字变了：", count());
});
// 输出: 数字变了：0 (初始化执行)
setCount(1);
// 输出: 数字变了：1 (自动触发！)
这就是细粒度响应式的最简内核。没有任何 VDOM，没有 Diff，只有精准的函数调用链。
三、 进阶： computed 与依赖图的自动构建
Signal 系统最强大的地方在于它能自动构建依赖图。 在架构设计中，我们经常使用 computed (派生状态)。
computed 既是 消费者（它依赖别的 Signal），又是 生产者（别的 Effect 依赖它）。
3.1 懒计算与缓存 (Memoization)
细粒度框架中的 computed 通常是惰性的（Lazy）。
- 只有当有人读它时，它才计算。
- 如果它依赖的 Signal 没变，它直接返回缓存。
3.2 动态依赖收集
这是 React useMemo 永远做不到的。 React 的依赖数组 [a, b] 是手动声明的（静态）。而 Signal 的依赖是运行时动态收集的。
const [show, setShow] = createSignal(true);
const [name, setName] = createSignal("Gemini");
const [age, setAge] = createSignal(18);
createEffect(() => {
// 动态依赖！
if (show()) {
console.log(name()); // 此时依赖是 [show, name]
} else {
console.log(age()); // 此时依赖变成 [show, age]
}
});
架构意义： 这种机制保证了最小化计算。当 show 为 false 时，改变 name 根本不会触发这个 Effect，因为系统知道这一刻 name 不重要。
四、 为什么 React 还在坚持？
既然 Signal 这么好，性能这么高，为什么 React 不把 useState 换成 Signal？ 这涉及到底层哲学的冲突。
4.1 UI = f(state) vs. UI = Bind(state)
- React 哲学： UI 是数据的投影（Snapshot） 。每次渲染都是丢弃旧世界，重建新世界。这符合函数式编程的直觉，心智模型最简单。
- Signal 哲学： UI 是数据的绑定（Binding） 。初始渲染后，组件就消失了，剩下的只有数据和 DOM 之间的连线。
4.2 代数效应 (Algebraic Effects)
React 团队认为，手动处理 .value 或者 [get, set] 是对开发者心智的负担。他们追求的是 "It just works" 。 React 正在搞的 React Compiler (React Forget) ，其实是一条殊途同归的路：
- Signal: 在运行时通过 Proxy 收集依赖，实现细粒度更新。
- React Compiler: 在编译时分析代码，自动插入 memoization，模拟细粒度更新的效果。
五、 总结：架构师的选择
理解了原理，我们在架构设计中就能明白：
-
Vue 3 / Solid: 适合高性能仪表盘、即时通讯、即时编辑类应用。因为它们对 CPU 的利用率极高，没有 VDOM 的 Overhead。
-
React: 适合大型业务系统、生态依赖重的应用。虽然有一些性能损耗，但其编程模型的一致性（Pure Render）能降低逻辑复杂度。
-
趋势: 越来越多的状态管理库（MobX, Valtio, Preact Signals）允许你在 React 中使用 Signal。
- 架构模式： 使用 Signal 管理频繁变化的局部状态（避免 React 顶层重渲染），使用 React Context 管理低频的全局状态。
Next Step: 我们搞懂了前端“怎么存数据”（Redux/Atomic）和“怎么更新数据”（Signal）。 但还有一个最大的麻烦没解决：API 数据。 我们以前总是把后端返回的 JSON 也塞进 Redux 里，导致 Redux 变得臃肿不堪。这真的是对的吗？ 下一节，我们将通过 React Query (TanStack Query) 来一场架构大扫除。 请看**《第三篇：分治——把 API 赶出 Redux：服务端状态 (Server State) 与客户端状态的架构分离》**。
