响应式内核怎么追依赖

Vue 的 ref、Preact 的 signal、Solid 的 createSignal——这些「改一个值，用到它的地方自动更新」的能力，底层都是同一套 push-pull 依赖追踪：谁读了谁（依赖图）用一张双向链表记下来，改值时先低成本地推一遍标记 (push)，真要用到时再沿版本号回头核对是否变脏 (pull)。本系列顺着 Preact「Signal Boosting」→ Vue 3.4 重写 → alien-signals 这条演进线，把这套内核逐步拆开：为什么不用 Set、版本号如何省掉无谓重算、push 和 pull 如何分工、Link 节点如何零分配复用。每一节都能单步观察依赖图里 Link 建立、version 号自增、dirty / pending 标记的置位与清除。

阅读本系列假定你用过任一响应式框架 (Vue / Preact / Solid)，了解 signal / computed / effect 的基本含义。

本页脉络：为什么需要一套内核 → 依赖图 + Link 双向链表 → 版本号 + lazy pull → propagate 推送 + 批处理 → 零分配 + Link 复用。

1 · 为什么需要一套内核：朴素响应式会重复计算

响应式要解决的事很朴素：派生值要在它依赖的源变化时自动更新。total = price * qty，改了 price,total 自己跟上。最直接的实现是「谁变了，就把用到它的派生值全部重算一遍」。可行，但一旦依赖图里出现钻石（一个值被两条路径共同依赖），它就会把同一个值算两遍，中间还会出现一个用了一半旧数据的错值 (glitch)。下面这个钻石单步运行即可看到：

1.1 · 另外两个问题

2 · 依赖图：谁读了谁，用双向链表记下来

响应式的第一步是知道谁依赖谁。没人手写这张图——它是跑出来的：让一个 effect 或 computed 跑一遍，它读到的每个 signal，就在「读者」和「被读者」之间建一条 Link。关键在 Link 不是单向的：它同时挂在两条链上——被读的 signal 的「下游 subscribers 链」、读者自己的「上游 dependencies 链」（Preact 管这叫 "quad-linked"）。这样「signal 变了要通知谁」和「这个 computed 依赖了谁」都是 O(1) 顺着链走，不用 Set。

2.1 · 为什么是双向链表，而不是 Set

最直觉的实现是：每个 signal 存一个 Set<subscriber>，每个 effect 存一个 Set<signal>。能用，但有代价：

• 增删要算 hash——Set.add / delete 要算哈希、可能 rehash；双向链表插入/删除一个 Link 节点是纯指针操作，O(1) 且无哈希开销。
• 每轮重跑都分配临时对象——effect 重跑要重建依赖集，朴素做法 new Set() 逐个 add，旧 Set 成为垃圾。链表可以原地复用同一批 Link 节点（见 零分配 + Link 复用）。
• 双向才能两头走——signal 变了要顺着「下游链」通知 subscribers (push);computed 要算时要顺着「上游链」核对 dependencies (pull)。两个方向都 O(1) 遍历，一条 Link 同时在两条链上。

3 · 版本号：先比对版本，一致就跳过重算

computed 是惰性的——不读不算，算完缓存。难点在：源变了之后，怎么不真的重算就知道某个缓存还能不能用？做法是给每个值挂一个单调递增的 version 号:signal 每次改值 version++；每条 Link 记下「上次读到时的版本」。要用某个 computed 时，checkDirty 沿它的依赖逐级比对版本号——全对得上 = 没人变过 = 直接用缓存；只要有一条对不上，才真的重算。版本号把「判断脏没脏」从「重算一遍看看」降成了「比几个整数」。

3.1 · 多级短路：它一层层省

Preact 的 computed 实际上有四道关卡，从最便宜到最贵，任何一关能否定「脏」就立刻返回缓存：

• 全局 version 关——自上次计算以来，没有任何 signal 改过值（全局 version 没动）→ 整个世界没变，直接用缓存。最便宜。
• 没被通知关——这个 computed 压根没被 propagate 标记过（没人通知它上游变了）→ 缓存有效。
• 依赖版本关——逐个依赖比对版本号（上图演示的就是这关）；全对得上 → 上游的值其实没变，不重算。
• 真重算——前三关都没拦住，才真的跑一遍 fn。算完若新值还等于旧值, version 仍不涨 → 下游继续短路。

4 · propagate：改值先推一遍标记，不立刻算

set 一个 signal 时，内核不顺着图把下游重算一遍——那样钻石依赖会重复算、一批改动会反复触发。它分成两段：push (propagate) 沿「下游链」把所有下游标成 pending（可能脏）、把 effect 入队，只标记、不计算，成本极低；pull (flush) 等这一轮改动都标记完成后，才对排队的 effect 跑 checkDirty 区分真脏假脏、真脏才算。这一步把「谁可能受影响」和「是否需要重算」拆开，换来两个收益：钻石只标一次、一批改动只 flush 一次。

4.1 · 批处理：一批改动，只跑一次 effect

既然 propagate 只标记、flush 才计算，那么把多次 set 之间的 flush 暂停，就能让一连串改动只在最后统一 flush 一次——这正是 Vue 的 pauseScheduling() / resetScheduling() 和 React 的批量更新所做的事。对比上面的 batch 与 不 batch：同样改 a 和 k，前者 effect 只跑 1 次，后者跑 2 次。

• 钻石去重——propagate 遇到已 pending 的节点直接跳过 → 一个 computed 一轮最多被标记一次、之后 checkDirty 也只算一次。从根上避免「算两遍」的 glitch。
• 值没变就不往下传 (Vue #5912)——flush 时若某 computed 重算后值没变（version 不涨），它的下游 checkDirty 一比版本就对上 → 停在这里，不再往下传播。version 演示过这个短路。
• effect 入队去重——同一个 effect 被多条路径标记，也只入队一次;flush 时一个 effect 只跑一遍。

5 · 零分配：Link 不重建，回收复用

每次 effect / computed 重跑，都要重新确定「这一轮读了谁」。朴素做法是每轮 new Set()，逐个 add——跑一万次就分配一万个临时 Set 交给 GC。现代内核采用另一种思路：用 startTracking / endTracking 把一次运行包裹起来。运行前，把这个节点现有的 Link 全标「这轮尚未读到」(used=false)；运行过程中读到谁，就把对应 Link 标 used=true——同一个 Link 对象原地复用，不分配；收尾时，凡是仍为 used=false 的 Link 就回收。依赖未变的轮次，新分配 = 0。

5.1 · 进一步：alien-signals 的约束

把「不分配」这条路走到底，就是 alien-signals 给自己定的硬性约束：

• 核心算法不用 Array / Set / Map——依赖关系全靠 Link 节点上的指针串成链表，不借助任何会动态扩容、产生垃圾的集合类型。
• 不用函数递归——propagate / checkDirty 改成迭代 + 显式栈（链表本身就能当栈用），避免深图爆栈、也省掉调用帧开销。
• 状态压入位标志 (flags)——dirty / pending / 正在运行 / 是否被订阅… 全部压进一个整数的不同 bit，判断和切换都是位运算。
• 结论——作者发现：把算法本身做简单，比堆叠复杂的调度策略更能提速。这套内核现已反过来被 Vue 借鉴。

6 · 它真实跑在哪里