响应式系统比对：链表实现高效更新的原理

前言

在深入解析 Computed 的延迟订阅策略之后，本文继续剖析 Effect 的即时订阅机制。两种策略，一慢一快，背后体现了响应式系统在正确性与性能之间的精妙平衡，同时也是 Preact Signals 核心设计哲学的重要体现。

Effect 的即时订阅实现

先看一个直观的例子，理解为什么 Effect 必须做到“即时响应”。

// 监听鼠标移动
const handleMouseMove = (e) => {
    console.log('移动', e)
};
const isActive = signal(true);
// 假设使用延迟订阅
effect(() => {
    console.log('执行 effect', isActive.value)
    if (isActive.value) {
        document.addEventListener('mousemove', handleMouseMove);
    } else {
        document.removeEventListener('mousemove', handleMouseMove);
    }
    isActive.value = false;
});

运行后会发现问题：只输出了一次“执行 effect”，鼠标监听并未被移除。根源在于 Effect 依赖了 isActive，按理说 isActive 变化时 Effect 应重新执行。但如果 Effect 也像 Computed 那样采用延迟订阅，那就永远不会被“订阅”——因为 Effect 本身就是订阅链条的终点，没有任何上游会订阅它。信号一旦变化，Effect 无法感知。

在 Preact Signals 的设计中，Effect 作为订阅链条的终端消费者，必须主动绑定依赖，即时建立通知通道。因此每次执行 Effect 时，它需立即订阅所依赖的信号，同时清理旧的订阅关系，因为条件分支可能导致依赖关系发生显著变化。

接下来看实现迭代过程：

// 省略...// 追踪当前 Effect 的执行深度
let effectDepth = 0
// 省略...function getValue(signal) {
    let node = void 0
    if (evalContext !== void 0 && signal._evalContext !== evalContext) {
        // 省略...
        signal._evalContext = evalContext
+        // 关键优化：只有 Effect 上下文才立即订阅
+        if (effectDepth > 0) {
+            signal._subscribe(node);  // Effect 中：立即建立订阅
+        }        
    }
    const value = signal.peek()
    if (evalContext && node) {
        node.nextSignal = evalContext._sources
        node.version = node.signal._version
        evalContext._sources = node
    }
    return value
}// 省略...class Computed extends Signal {
    _invalidate() {
+        // 性能优化，如果已经脏了，就不用递归通知了
+        if (this._valid) {
            this._valid = false
            for (let node = this._targets; node; node = node.nextTarget) {
                node.target._invalidate()
            }
+        }
    }
}// 省略...class Effect {
    _start() {
        // 省略...
        const prevRollback = currentRollback;
+        effectDepth++
        // 省略...
    }
    _end(oldSources, prevContext, prevRollback) {
+        effectDepth--
        // 省略...
    }
}

核心思路是借助一个 effectDepth 变量标记当前是否处于 Effect 执行过程中。通过在 _start 和 _end 中进行增减，可以区分三种执行上下文：

• effectDepth = 0：Computed 或非 Effect 环境
• effectDepth = 1：最外层 Effect
• effectDepth > 1：嵌套 Effect

当读取信号（调用 getValue）时，只有 effectDepth > 0 才会立即执行订阅。也就是说，在 Effect 内读取信号才绑定依赖，而在 Computed 内读取信号则不绑定——Computed 仍然等待别人订阅它时再统一建立关联关系。

有人可能会问：_end 中不是还调用了 subscribeToAll 吗？那岂不是重复订阅？确实存在这种冗余，但 Signal 的 _subscribe 方法内部已经做了去重检查，因此最多多消耗一次函数调用，并不会重复绑定。不过这种冗余在后续优化中已被移除。

总结来看：Effect 追求即时响应，Computed 追求高效缓存。同一套系统中两种策略并存，各取所长，展现了 Preact Signals 按场景进行优化的设计思想。

循环迭代限制机制

编写 Effect 时很容易陷入一种经典陷阱——无限自增：

const A = signal(0);
effect(() => {
    A.value = A.value + 1;  // 每次执行都改自己
});
A.value = 1;  // 触发无限循环

运行结果：Uncaught RangeError: Maximum call stack size exceeded，典型的栈溢出错误。

回顾 Preact Signals 的批处理原理：endBatch 会遍历队列逐个执行 Effect，而 Effect 执行过程中可能再次修改信号，从而将新的 Effect 加入队列。如果这个循环无法终止，就会无限嵌套下去。解决办法十分直接——添加一个计数器 batchIteration，每轮循环自增一次，一旦超过预设阈值（例如100）就抛出错误。

// 省略...
let batchDepth = 0
+ let batchIteration = 0
// 省略...
function endBatch() {
+    if (batchDepth > 1) {
+        batchDepth--
+        return
+    }
    while (currentBatch) {
        const batch = currentBatch
        currentBatch = undefined
+        batchIteration++
        for (let item = batch; item; item = item.next) {
            const runnable = item.effect
            runnable._batched = false
            runnable._notify()
        }
    }
+    batchIteration = 0
+    batchDepth--
}

class Signal {
    set value(value) {
        if (this._value !== value) {
+            if (batchIteration > 100) {
+                throw new Error("Cycle detected")
+            }
            // 省略...
        }
    }
}

改造之后，再运行上述代码，会打印出清晰的错误信息：Uncaught Error: Cycle detected。这避免了程序卡死或栈溢出，对开发者更加友好。

注意 batchIteration 只在最外层的批处理循环中递增，嵌套的批处理不会影响它。同时 endBatch 中先判断如果 batchDepth > 1 则直接返回，确保只有最外层才真正执行队列。当循环执行超过100次仍未清空时，基本可以确认存在循环依赖，提前拦截。

统一订阅上下文管理

之前的 effectDepth 只管理了 Effect 的嵌套深度，但在 Computed 执行时也会进入 getValue，而 Computed 内部读取信号时是否需要立即订阅？最初的设计是只有 Effect 才立即订阅。但后来发现，如果 Computed 存在订阅者，它也需要立即订阅——因为它的订阅者可能是 Effect，延迟订阅会导致 Effect 收不到变更通知。

举例说明：A = computed(() => B.value)，C = effect(() => A.value)。如果 A 延迟订阅 B，那么 B 变化时 A 不会主动更新，C 也就无法感知变化。因此，有订阅者的 Computed 也应当立即订阅。

于是将 effectDepth 升级为 subscribeDepth：

// 省略...
- // let effectDepth = 0
+ let subscribeDepth = 0

// 省略...
function getValue(signal) {
    // 省略...
    if (evalContext !== void 0 && signal._evalContext !== evalContext) {
        // 省略...
-        if (effectDepth > 0) {
-            signal._subscribe(node);
-        }
+        if (subscribeDepth > 0) {
+            signal._subscribe(node);
+        }
    }
    // 省略...
}

同时，在 Computed 的 peek() 方法中，如果它有订阅者，就在计算开始前执行 subscribeDepth++，计算结束后执行 subscribeDepth--。这样在 Computed 的计算函数中读取信号时，也会触发即时订阅。而 Effect 的 _start 和 _end 也相应改为操作 subscribeDepth。

这样一来，无论是在 Effect 还是在有订阅者的 Computed 中，依赖收集与即时订阅一气呵成，不再需要在计算结束后再调用 subscribeToAll 进行批量订阅。下面通过一段测试代码，用日志对比优化前后的效果：

const active = signal(true)
const computeValue = computed(() => active.value)
effect(() => console.log('读取', computeValue.value))
console.log('切换 active')
active.value = false

优化前的日志输出：

订阅 undefined
执行计算函数
订阅 true          // getValue 中的立即订阅
执行计算函数完毕
订阅 true          // computed._end() 中的 subscribeToAll
读取 true
执行 effect _end
订阅 true          // effect._end() 中的 subscribeToAll（重复）
切换 active
订阅 true
执行计算函数
订阅 false
执行计算函数完毕
订阅 false
读取 false
执行 effect _end
订阅 false

每次信号变化都会产生3次订阅操作，虽然 _subscribe 做了去重，但函数调用和循环遍历的开销依然存在。

优化后的日志输出：

订阅 undefined
执行计算函数
订阅 true
执行计算函数完毕
读取 true
执行 effect _end
切换 active
订阅 true
执行计算函数
订阅 false
执行计算函数完毕
读取 false
执行 effect _end

订阅次数从3次减少到1次，优化效果立竿见影。核心变化就是移除了 subscribeToAll，避免了重复的循环遍历和订阅操作。

这次迭代不仅是性能提升，更是订阅机制的一次深度重构。通过统一的 subscribeDepth，系统现在能够智能区分订阅时机：有订阅者的 Computed 也立即订阅，无订阅者的 Computed 依然保持延迟。做到了按需响应、干净利落。

优化回滚机制的性能

来看回滚部分的改进。之前每次在 getValue 中创建新依赖节点时，如果信号已经有 _evalContext（旧节点），我们会创建一个回滚节点来保存旧状态，以便后续恢复。问题在于很多情况下 _evalContext 是 undefined，此时创建回滚节点纯粹是白费功夫——内存分配和链表操作都毫无意义。

优化方案很简单：只有 signal._evalContext 存在时才创建回滚节点。

// 省略...
function getValue(signal) {
    let node = void 0
    if (evalContext !== void 0 && signal._evalContext !== evalContext) {
+        if (signal._evalContext) {
+            currentRollback = { 
+                signal: signal,
+                evalContext: signal._evalContext,
+                next: currentRollback
+            }
+        }
        // 省略...
    }
    // 省略...
}

同时，我们在 Computed 和 Effect 的清理逻辑中主动清除信号的 _evalContext 引用，避免残留。这些微优化在普通应用中可能不易察觉，但在大型状态频繁更新的场景下，累积效果相当可观。

防止计算信号的无限递归

还有一种经典错误：计算信号自我引用。

const count = signal(0);
const circular = computed(() => {
    return circular.value + 1;  // 读取自己，死循环
});
console.log(circular.value);  // 应该抛错

解决方案是增加一个 _computing 标志，在进入 peek() 时进行检查，如果已经在计算中，直接抛出错误。

class Computed extends Signal {
+    _computing = false
    peek() {
+        if (this._computing) {
+            throw new Error("cycle detected");
+        }
        try {
+            this._computing = true
            // 省略...
        } finally {
+            this._computing = false
            // 省略...
        }
    }
}

这样一来，开发者就能得到清晰的错误提示，而非程序崩溃或无限循环。

修改信号追踪逻辑

旧设计中，信号通过 _evalContext 记录当前访问它的上下文（Effect或Computed）。这只是一个简单的引用，不包含完整的节点信息（例如 nextSignal、version）。这意味着如果想通过信号访问其依赖节点的细节，就需要遍历链表，很不方便。

新设计将 _evalContext 替换为 _node，直接存储信号对应的依赖节点对象。这样信号可以一步到位获取完整信息。

// 旧设计
signal._evalContext = evalContext
// 新设计
signal._node = { signal, target: evalContext, nextSignal: ..., version: ... }

相应地，回滚机制也从恢复 _evalContext 变为恢复 _node：

// 旧回滚
rollback.signal._evalContext = rollback.evalContext;
// 新回滚
rollback.signal._node = rollback.node;

节点生命周期管理也变得更加显式。以前通过 unsubscribeFromAll 间接清理，现在直接遍历链表，对每个节点调用 _unsubscribe 并手动置空 nextSignal，帮助垃圾回收。

let node = oldSources;
while (node) {
    const next = node.nextSignal;
    node.signal._unsubscribe(node);
    node.nextSignal = undefined;  // 显式断开
    node = next;
}

这次重构让依赖关系管理更加直接，也为后续的节点重用奠定了基础。

回收和重用链表节点

现在每次依赖收集都会创建新节点，计算或 Effect 结束后又将节点丢弃。如果状态频繁更新，内存分配和 GC 压力会相当明显。

我们做了一个实验：用一个 Effect 读取同一个信号，更新信号值，观察节点创建次数。

const count = signal(1)
effect(() => {
    console.log('读取信号', count.value)
})
console.log('更新')
count.value = 2

在 getValue 中增加日志，结果如下：

创建节点
读取信号 1
更新
创建节点
读取信号 2

每次更新都重新创建节点，浪费严重。我们的目标是：如果同一个 Effect 下次执行时依赖的仍然是这些信号，就不要新建节点，而是复用旧的。

实现思路是给节点增加一个 used 标志。在计算开始前，通过 prepareSources 将当前节点的 used 设为 false，并保存回滚信息。计算过程中，如果遇到已有节点且属于当前上下文，将其 used 设为 true；否则才创建新节点。计算结束后，通过 cleanupSources 清理未被使用的节点（取消订阅、断开引用），保留已被使用的节点。

function getValue(signal) {
    let node = undefined
    if (evalContext) {
        node = signal._node
        if (!node || node.target !== evalContext) {
            // 新节点创建逻辑...
        } else if (!node.used) {
            node.used = true  // 复用了旧节点
        } else {
            node = undefined  // 避免重复更新版本号
        }
    }
    const value = signal.peek()
    if (node) {
        node.version = node.signal._version
    }
    return value
}

再次运行同样的测试，结果如下：

创建节点
读取信号 1
更新
读取信号 2

第二次更新不再创建新节点，完美复用。这显著减少了内存分配和 GC 频率。

使用 Effect 对象作为批处理链表节点

批处理队列目前的做法是使用一个包装对象 { effect: this, next: currentBatch } 来连接 Effect。这同样造成了不必要的内存分配。既然 Effect 对象本身就是一个节点，为什么不能让它直接参与链表链接？

改造很直接：为 Effect 增加 _nextEffect 字段，在入队时把自己挂上去。

// 队列头
- let currentBatch = undefined
+ let batchedEffect = undefined

// 入队
- currentBatch = { effect: this, next: currentBatch };
+ this._nextEffect = batchedEffect;
+ batchedEffect = this;

// 遍历执行
- for (let item = batch; item; item = item.next) {
-     item.effect._notify();
- }
+ while (effect) {
+     const next = effect._nextEffect;
+     effect._nextEffect = undefined;
+     effect._batched = false;
+     effect._notify();
+     effect = next;
+ }

消除了包装对象，直接复用 Effect 实例。这项优化与节点重用策略形成了完美的协同：依赖收集时复用节点，批处理时复用 Effect。中间层的逐个消除，自然带来了性能提升。

移除独立回滚缓冲区

之前我们使用了一个全局 currentRollback 链表，专门记录信号 _node 的旧值，以便在计算失败或退出时进行恢复。这和批处理包装对象一样，也是多余的内存分配。

这次我们将回滚信息直接嵌入到依赖节点中。每个节点新增一个 rollbackNode 字段，在创建新节点或调用 prepareSources 时，把信号当前的 _node 存储进去。然后在 cleanupSources 时，遍历所有节点，通过 rollbackNode 恢复信号的旧引用。

// 创建节点时
node = {
    signal: signal,
    target: evalContext,
    nextSignal: evalContext._sources,
    version: 0,
    used: true,
+    rollbackNode: node  // 保存旧节点
};

// prepareSources 中
+ const rollbackNode = node.signal._node;
+ if (rollbackNode) {
+     node.rollbackNode = rollbackNode;
+ }
+ signal._node = node;

// cleanupSources 中
- node.signal._node = undefined;
+ node.signal._node = node.rollbackNode;
+ if (node.rollbackNode) {
+     node.rollbackNode = undefined;
+ }

这样一来，全局 currentRollback 就彻底不需要了，相关代码全部移除。回滚信息分散在各个节点中，既减少了内存分配，又简化了代码逻辑。

总结

从 Effect 即时订阅出发，我们一路迭代了循环限制、统一订阅上下文、回滚优化、无限递归防护、信号追踪重构、节点重用、批处理链表内嵌、回滚信息内嵌。这些改进并非零散的补丁，而是遵循“消除中间对象、复用现有结构、按场景区分策略”的设计哲学，在保证正确性的前提下，大幅降低了内存分配和 GC 压力，提升了依赖收集和通知的执行效率。

最终的系统拥有更清晰的节点生命周期、更智能的订阅时机判断、更稳健的循环检测。这套演进思路，对于同类框架的优化实践也具有不错的参考价值。