第 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 由引擎管理，无法被应用层复用。

双向链表的视觉模型

让我们用一个具体的例子来理解 Link 双向链表的结构：

typescript

const price = ref(10)
const quantity = ref(3)
const total = computed(() => price.value * quantity.value)

effect(() => {
  console.log(`Total: ${total.value}`)
})

这段代码建立的依赖关系如下：

total（computed）作为 Subscriber，通过 Link 1 和 Link 2 订阅了 price 和 quantity
total（computed）同时作为 Dep，通过 Link 3 被 effect 订阅
每个 Link 节点同时连接在两条链上——这就是"双向"的含义

Dep 类的完整实现

typescript

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

export class Dep {
  // 版本号——每次触发更新时递增
  _version: number = 0

  // 订阅者链表的头指针
  _subs: Link | undefined = undefined

  // 全局版本号（用于 computed 的快速路径优化）
  _globalVersion: number = globalVersion

  /**
   * 依赖收集：建立 Dep → Subscriber 的连接
   */
  track(): Link | undefined {
    // 获取当前正在执行的 subscriber（effect 或 computed）
    let link = this._subs

    // 如果当前 subscriber 已经订阅了这个 dep，复用 Link
    if (link && link.sub === activeSub) {
      return link
    }

    // 创建新的 Link 节点
    link = new Link(this, activeSub!)

    // 将 Link 加入 Dep 的 subs 链表（头插法）
    if (this._subs) {
      this._subs.prevSub = link
    }
    link.nextSub = this._subs
    this._subs = link

    // 将 Link 加入 Subscriber 的 deps 链表（尾插法）
    if (activeSub!._depsTail) {
      activeSub!._depsTail.nextDep = link
      link.prevDep = activeSub!._depsTail
    } else {
      activeSub!._deps = link
    }
    activeSub!._depsTail = link

    return link
  }

  /**
   * 触发更新：通知所有订阅者
   */
  trigger(): void {
    this._version++
    globalVersion++
    if (this._subs) {
      propagate(this._subs)
    }
  }
}

💡 最佳实践
注意 track() 中的复用检查（第一个 if 分支）。在 effect 重新执行期间，依赖往往和上一次相同。链表结构天然支持"顺序遍历 + 原地复用"——如果当前 Dep 的最近订阅者就是当前 Subscriber，直接返回已有的 Link，不创建新对象。这个微优化在"依赖稳定"的常见场景下，将依赖收集的开销降到了近乎为零。

Subscriber 接口

typescript

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

interface Subscriber {
  _deps: Link | undefined      // 依赖链表头
  _depsTail: Link | undefined  // 依赖链表尾
  _flags: number               // 状态标志位
}

// 标志位定义
const enum SubscriberFlags {
  DIRTY = 1 << 0,           // 确认脏——需要重算
  MAYBE_DIRTY = 1 << 1,     // 可能脏——需要检查依赖
  COMPUTED = 1 << 2,        // 是 computed
  NOTIFIED = 1 << 3,        // 已加入调度队列
  TRACKING = 1 << 4,        // 正在收集依赖
  RECURSED = 1 << 5,        // 用于防止递归传播
  RUNNING = 1 << 6,         // 正在执行
}

6.3 版本计数：告别标记位的脏检查

什么是版本计数？

版本计数是 Alien Signals 中最优雅的设计之一。每个 Dep 都维护一个递增的 _version 整数，每个 Link 节点也缓存一个 _version。判断依赖是否变化，只需要比较两个整数：

typescript

// 判断某个依赖是否发生了变化
function isDirty(link: Link): boolean {
  return link._version !== link.dep._version
}

这比 Vue 3.0 的"清理所有 Set 并重建"和 Vue 3.2 的"双缓冲标记位"都要简洁得多。

三代脏检查策略对比

策略	Vue 3.0	Vue 3.2–3.4	Vue 3.5（Alien Signals）
机制	清空 deps Set，重新收集	`w`/`n` 双标记位	版本号比较
每次 effect 执行前	遍历所有 deps，从 Set 中 delete	给所有旧 deps 打 `w` 标记	无操作（惰性检查）
每次依赖收集时	Set.add()	打 `n` 标记	比较 version，命中则跳过
每次 effect 执行后	无（已在执行前清理）	移除 `w=1, n=0` 的失效依赖	移除链表尾部多余的 Link
时间复杂度	O(n) 清理 + O(n) 重建	O(n) 标记 + O(n) 清理	O(changed) — 只处理变化的部分
内存开销	Set 对象 × 属性数	Set 对象 × 属性数	Link 节点 × 依赖数

版本计数的工作流程

typescript

// 第一次执行 effect
const count = ref(0)        // count.dep._version = 0
const doubled = computed(() => count.value * 2)

effect(() => {
  console.log(doubled.value)
})

// 1. effect 执行，读取 doubled.value
// 2. doubled 读取 count.value → 创建 Link(count.dep, doubled)
//    Link._version = count.dep._version = 0
// 3. doubled 计算完成 → 创建 Link(doubled.dep, effect)
//    Link._version = doubled.dep._version = 0

// 修改 count
count.value = 1
// 1. count.dep._version 变为 1
// 2. Link._version 仍为 0 → 版本不匹配 → dirty！
// 3. doubled 被标记为 MAYBE_DIRTY
// 4. 当 effect 检查 doubled 时，doubled 重算
// 5. doubled 值变了 → doubled.dep._version 变为 1
// 6. effect 重新执行

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

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

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

信号社区的启发 ​

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

告别 Set，拥抱链表 ​

双向链表的视觉模型 ​

Dep 类的完整实现 ​

Subscriber 接口 ​

6.3 版本计数：告别标记位的脏检查 ​

什么是版本计数？ ​

三代脏检查策略对比 ​

版本计数的工作流程 ​

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

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

Vue 3.0–3.4 的依赖存储架构

信号社区的启发

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

告别 Set，拥抱链表

双向链表的视觉模型

Dep 类的完整实现

Subscriber 接口

6.3 版本计数：告别标记位的脏检查

什么是版本计数？

三代脏检查策略对比

版本计数的工作流程