第 6 章 Vue 3.5 Alien Signals：响应式的第三次革命

本章要点
Alien Signals 的设计动机：为什么 Vue 需要第三代响应式内核
从 WeakMap 到 Link 双向链表：依赖存储结构的彻底重构
版本计数（Version Counting）：如何用整数替代 Set 遍历
混合推拉模型（Push-Pull）：computed 的惰性求值革命
Dep 与 Subscriber 的双向链表协议：Link 节点的六指针设计
propagate() 与 checkDirty()：信号传播的完整链路
性能基准对比：Alien Signals vs Vue 3.4 vs Solid.js vs Preact Signals

2024 年 9 月的一个深夜，Vue 核心团队成员 Johnson Chu 在 GitHub 上创建了一个不起眼的仓库——stackblitz/alien-signals。仓库描述只有一句话："The fastest signal library."（最快的信号库。）

两个月后，这个"外星信号"库的核心算法被 Evan You 合并进了 Vue 3.5 的 @vue/reactivity。基准测试显示，新的响应式系统在依赖传播速度上提升了 40-60%，内存占用降低了 56%，GC 压力几乎归零。这不是一次渐进式优化——这是一次底层架构的彻底重写。

从 Vue 3.0 到 Vue 3.4，响应式系统经历了两次重大演进：第一次是从 Object.defineProperty 到 Proxy（Vue 2 → Vue 3.0），解决了"不能检测新增属性"的历史顽疾；第二次是清理标记优化（Vue 3.2 → Vue 3.4），用双缓冲标记位替代了 Set 的全量清理。但这两次改进本质上都在同一个架构范式内——WeakMap → Map → Set 的三层映射结构始终是依赖存储的核心。

Alien Signals 打碎了这个范式。它用双向链表替代了 Set，用版本计数替代了标记位清理，用混合推拉模型替代了纯推模型。这不是"更快的同一条路"，而是"换了一条完全不同的路"。

本章将深入这条"外星之路"的每一个设计决策，从底层数据结构到高层传播算法，完整剖析 Vue 3.5 响应式内核的第三次革命。

6.1 问题的本质：旧系统出了什么问题？

Vue 3.0–3.4 的依赖存储架构

在理解 Alien Signals 之前，我们需要先理解它要解决的问题。Vue 3.0–3.4 的依赖存储使用经典的三层映射结构：

typescript

// Vue 3.0–3.4 的依赖存储（概念模型）
type TargetMap = WeakMap<object, KeyMap>
type KeyMap = Map<string | symbol, Dep>
type Dep = Set<ReactiveEffect>

// 全局的依赖存储
const targetMap: TargetMap = new WeakMap()

这个设计直觉而清晰：对于每一个响应式对象的每一个属性，都有一个 Set 存储所有依赖它的 effect。当属性被修改时，遍历 Set，执行每一个 effect。

但三个问题逐渐浮现：

问题一：内存开销

每一个属性的 Dep 都是一个 Set 对象。在现代 JavaScript 引擎中，一个空 Set 至少占用 64-128 字节。一个拥有 50 个响应式属性的组件，仅依赖存储就需要 3-6KB。当页面有数百个组件时，这个数字变得触目惊心。

typescript

// 粗略估算
const emptySetSize = 64  // V8 中一个空 Set 的内存开销（字节）
const propsPerComponent = 50
const components = 500

const totalOverhead = emptySetSize * propsPerComponent * components
// = 64 * 50 * 500 = 1.6 MB — 仅用于存储依赖关系！

问题二：GC 压力

每次 effect 重新执行时，旧的依赖关系需要被清理，新的依赖关系需要被重建。在 Vue 3.0 中，这意味着清空所有 Set 并重新添加——每次组件更新都会产生大量的临时对象，给垃圾回收器带来巨大压力。

typescript

// Vue 3.0 的依赖清理（简化）
function cleanupEffect(effect: ReactiveEffect) {
  const { deps } = effect
  for (let i = 0; i < deps.length; i++) {
    deps[i].delete(effect)  // 从每个 Dep Set 中移除自己
  }
  deps.length = 0  // 清空 deps 数组
}

Vue 3.2 引入了"双缓冲标记位"优化（w 和 n 标记），避免了全量清理：

typescript

// Vue 3.2–3.4 的优化：用标记位替代全量清理
// w = was tracked（执行前已存在的依赖）
// n = newly tracked（本次执行新收集的依赖）
// 执行完后，w=1 但 n=0 的依赖需要被移除（条件分支不再走到的路径）

但这只是治标——Set 本身的内存开销和 hash 查找的 CPU 开销并没有减少。

问题三：传播效率

在纯推模型中，当一个 ref 被修改时，所有依赖它的 effect 立即被触发，包括那些最终结果不会改变的 computed：

typescript

const firstName = ref('John')
const lastName = ref('Doe')
const fullName = computed(() => `${firstName.value} ${lastName.value}`)
const greeting = computed(() => `Hello, ${fullName.value}!`)

// 修改 firstName
firstName.value = 'John'  // 赋了相同的值！
// 纯推模型：fullName 被触发重算 → greeting 被触发重算
// 但其实 fullName 的值没变，greeting 的重算完全是浪费

这三个问题——内存、GC、传播效率——不是 bug，而是架构的固有局限。要从根本上解决它们，需要换一种思路。

信号社区的启发

2023-2024 年，前端社区掀起了一场"信号革命"（Signals Revolution）。Solid.js、Preact Signals、Angular Signals 相继证明了一种新的响应式范式的可行性：

特性	Vue 3.0–3.4	Solid.js	Preact Signals	Alien Signals
依赖存储	WeakMap→Map→Set	链表	链表	双向链表
传播模型	纯推	推拉混合	推拉混合	推拉混合
脏检查	标记位	版本计数	版本计数	版本计数
computed 求值	推送时重算	读取时重算	读取时重算	读取时重算
内存模型	对象密集	链表节点	链表节点	链表节点

Johnson Chu 的贡献在于：他不仅吸收了社区的最佳实践，还在数据结构层面做了极致优化——Alien Signals 的 Link 节点设计比 Preact Signals 更紧凑，依赖遍历比 Solid.js 更高效。在 js-reactivity-benchmark 基准测试中，Alien Signals 在几乎所有项目上都排名第一。

6.2 核心数据结构：Link 双向链表

告别 Set，拥抱链表

Alien Signals 的核心革新在于用 Link 节点 组成的双向链表替代了 Set 来存储依赖关系。每个 Link 节点同时参与两条链表——Dep 的订阅者链和 Subscriber 的依赖链——实现了"一个节点、双向连接"的极致内存效率。

typescript

// packages/reactivity/src/dep.ts（简化）

/**
 * Link 节点——连接 Dep 和 Subscriber 的桥梁
 *
 * 每个 Link 同时存在于两条链表中：
 * 1. Dep 的 subs 链表（nextSub / prevSub）
 * 2. Subscriber 的 deps 链表（nextDep / prevDep）
 */
interface Link {
  dep: Dep              // 指向依赖源
  sub: Subscriber       // 指向订阅者

  // Dep 维度的链表指针
  nextSub: Link | undefined   // Dep 的下一个订阅者
  prevSub: Link | undefined   // Dep 的上一个订阅者

  // Subscriber 维度的链表指针
  nextDep: Link | undefined   // Subscriber 的下一个依赖
  prevDep: Link | undefined   // Subscriber 的上一个依赖（Vue 3.5 中为 tail 指针复用）
}

🔥 深度洞察
为什么用链表替代 Set？三个原因：
内存连续性：Link 是一个纯数据对象（6 个指针 + 2 个引用），在 V8 中只占约 80 字节。而一个包含 1 个元素的 Set 需要约 128 字节——Set 自身的开销就超过了 Link 节点。当依赖关系数量为 N 时，链表方案节省的内存随 N 线性增长。
O(1) 操作：链表的插入和删除都是 O(1)，而 Set 的 delete 操作虽然平均 O(1)，但需要 hash 计算和可能的冲突处理。在高频率的依赖收集/清理场景中，链表的常数因子更小。
零 GC 压力：Link 节点可以被缓存和复用（通过对象池或 free list），而 Set 的内部 bucket 由引擎管理，无法被应用层复用。

第 6 章 Vue 3.5 Alien Signals：响应式的第三次革命 ​

6.1 问题的本质：旧系统出了什么问题？ ​

Vue 3.0–3.4 的依赖存储架构 ​

信号社区的启发 ​

6.2 核心数据结构：Link 双向链表 ​

告别 Set，拥抱链表 ​

第 6 章 Vue 3.5 Alien Signals：响应式的第三次革命

6.1 问题的本质：旧系统出了什么问题？

Vue 3.0–3.4 的依赖存储架构

信号社区的启发

6.2 核心数据结构：Link 双向链表

告别 Set，拥抱链表