## 前言上一篇我把 Vue 3 响应式的主线——从 Proxy 到 track/trigger，从 targetMap 三层结构到四种 effect 的调度分叉——完整串了一遍。但写完之后我发现，effect 内部有几个设计，单独拿出来都懂，合在一起就容易乱。比如： - `key.dep` 和 `effect.deps` 到底什么关系？为什么互相指着？ - scheduler 到底怎么决定执行策略？分叉点在哪里？ - cleanup 为什么必须做？不做会怎样？这篇文章专讲这三个问题。它们不是三个独立的知识点，而是一套互相咬合的设计——**scheduler 决定“什么时候执行”，cleanup 确保“只依赖该依赖的”，双向记录为 cleanup 提供“快速找到自己”的能力。** --- ## 一、effect：不只是“要跑的函数”，它是一个完整的上下文对象 ### 1.1 effect 的直觉理解很多人（包括以前的我）会把 effect 简单理解成“数据变了要重新跑的函数”。这个理解不算错，但太粗糙。更准确地说：**effect 是一个“带依赖追踪和调度能力的副作用上下文”。** ```javascript class ReactiveEffect { fn: Function // 要执行的函数（副作用本身） scheduler?: () => void // 调度器（决定怎么执行） deps: Dep[] = [] // 记录自己被哪些 Dep 收集了（双向记录） parent?: ReactiveEffect // 指向外层 effect（嵌套时用） run() { // 执行 fn，并在执行期间把自己设为 activeEffect // 这样 fn 里读到的所有响应式数据，都能通过 track 找到自己 } } ``` 一个 effect 在生命周期里经历三个阶段： 1. **创建**：决定它是哪种类型（配什么 scheduler） 2. **收集**：`run()` 时把自己挂成 activeEffect，读数据时被 track 收录 3. **触发**：数据变了，trigger 找到它，有 scheduler 就调 scheduler，没有就调 run ### 1.2 activeEffect：为什么需要一个全局变量这是很多人卡住的第一个点——**“正在执行的 effect”为什么要用全局变量标记？** 答案很简单：Proxy 的 get trap 是自动触发的，不是手动传参调用的。 ```javascript // 假设没有 activeEffect，你只能这样传： function track(target, key, effect) { ... } // 但 Proxy get 的签名是固定的，没地方传 effect： get(target, key, receiver) { track(target, key) // 谁来调？谁在读？track 怎么知道？ } ``` 所以必须有一个全局变量作为“副作用通道”： ```javascript let activeEffect = null class ReactiveEffect { run() { activeEffect = this // 执行前，告诉全世界“现在是我在跑” const result = this.fn() activeEffect = null // 执行完，恢复 return result } } function track(target, key) { if (!activeEffect) return // 不是 effect 触发的读，不收集 // 现在 track 就知道是谁在读这个数据了 dep.add(activeEffect) } ``` **activeEffect 就是“谁在用这个数据”的运行时上下文。** 嵌套 effect 时，用 parent 指针+栈式结构保证内外层不混淆： ```javascript run() { // 保存外层 this.parent = activeEffect // 把自己设为当前 activeEffect = this // ... // 恢复外层 activeEffect = this.parent } ``` --- ## 二、双向依赖：dep → effect 和 effect → deps ### 2.1 什么是双向记录先看一个具体例子： ```javascript const person = reactive({ name: '张三', age: 18 }) effect(() => { console.log(person.name, person.age) }) // 假设这个 effect 叫 effect1 ``` 此时数据结构长这样： ``` targetMap (WeakMap): person → Map { 'name' → Set { effect1 }, ← 这就是 name.dep 'age' → Set { effect1 } ← 这就是 age.dep } effect1.deps: [ name.dep, age.dep ] ```

图 1：targetMap 三层嵌套结构。person 作为 WeakMap 的 key，其 value 是 Map（属性名 → dep Set）；dep 存 effect 引用，effect.deps 反向指回 dep——两条索引分别服务 trigger 与 cleanup。

**dep 知道“谁依赖我”，effect 知道“我依赖谁”——互相指着，这就是双向记录。** ### 2.2 正向：dep → effect，给 trigger 用 ```javascript // 数据变了，要通知依赖者 person.name = '李四' // trigger 要做的事： function trigger(target, key) { const dep = targetMap.get(target)?.get(key) // 通过 target+key 找到 dep if (!dep) return dep.forEach(effect => { // dep 里直接存着所有依赖这个 key 的 effect // O(1) 找到，O(n) 遍历触发 if (effect.scheduler) { effect.scheduler() } else { effect.run() } }) } ``` **有了 dep → effect，trigger 时不用遍历所有 effect 去找谁依赖了这个 key。** ### 2.3 反向：effect → deps，给 cleanup 用 **为什么需要反向记录？因为依赖不是静态的。** ```javascript effect(() => { if (person.flag) { console.log(person.name) // 依赖 name } else { console.log(person.age) // 依赖 age } }) ``` **第一次执行（flag = true）**： ``` person.name.dep = Set { effect } person.age.dep = Set { } // 没读，空的 effect.deps = [ person.name.dep ] ``` **flag 变成 false，第二次执行**——此时必须把 effect 从 `person.name.dep` 里删掉： ```javascript function cleanupEffect(effect) { // 遍历 effect.deps，从每个 dep 中删除自己 for (const dep of effect.deps) { dep.delete(effect) // 从 dep(Set) 中移除 } effect.deps.length = 0 // 清空 deps } ``` 在这个例子里，cleanup 只遍历了 `effect.deps = [person.name.dep]`，直接找到 `person.name.dep` 这个 Set，把自己删掉。**O(n)，n 是当前 effect 依赖的 key 数量，通常很小。** ### 2.4 如果没有反向记录如果只有 `dep → effect`，没有 `effect → deps`，cleanup 会变成什么？ ```javascript // 想清理旧依赖，你只能： // 遍历 targetMap 里的所有 WeakMap key（所有响应式对象） // → 遍历每个 key 的 Map（对象的所有属性） // → 遍历每个 dep Set // → 检查 "这个 effect 在不在里面" // 这就不是 O(n) 了，是 O(所有响应式对象 × 所有属性 × 所有依赖) ``` **双向记录的本质，是给两个查找方向各建一条索引：** - **dep → effect**：trigger 时，知道“这个 key 变了要通知谁” - **effect → deps**：cleanup 时，知道“我之前存在哪些 dep 里，该从哪里删自己” 所以这不是双向链表，是两个独立的数据结构各自存一份引用。dep 是 Set 的一个成员关系，effect.deps 是数组里的一个元素，它们之间没有 prev/next 指针，也不构成链表结构。

图 2：双向依赖的本质。左 dep 是 Set、右 effect.deps 是数组，两条相向箭头代表逻辑上的互相持有引用——但它们都是独立数据结构，并不像双向链表那样用 prev/next 指针串联节点。

--- ## 三、cleanup：每次重新收集，确保依赖永不过期 ### 3.1 完整的执行流程把 cleanup 放进 `effect.run()` 的完整流程： ```javascript class ReactiveEffect { run() { // 第一步：清理旧依赖 cleanupEffect(this) // 此时：effect 不再存在于任何 dep 中，effect.deps = [] // 第二步：标记自己为当前 effect this.parent = activeEffect activeEffect = this // 第三步：执行 fn，重新建立依赖 const result = this.fn() // fn 里读到 person.name // → track → person.name.dep.add(this) // → this.deps.push(person.name.dep) // 第四步：恢复 activeEffect = this.parent return result } } ``` **每一次 `effect.run()` 都是一次完整的“清旧—建新”循环。** 执行完以后，`effect.deps` 里只包含“这一次执行真正读到的 key 的 dep”。 ### 3.2 一个完整的分支依赖例子 ```javascript const state = reactive({ flag: true, a: 'a', b: 'b' }) const myEffect = new ReactiveEffect(() => { if (state.flag) { console.log(state.a) } else { console.log(state.b) } }) // === 第一次执行：flag = true === effect.run() // cleanupEffect: effect.deps = []，没什么可清 // activeEffect = effect // 执行 fn → 读 state.flag → track，state.flag.dep 加入 effect // 读 state.a → track，state.a.dep 加入 effect // 结果： // state.flag.dep = Set { effect } // state.a.dep = Set { effect } // effect.deps = [ state.flag.dep, state.a.dep ] // === 修改 state.flag = false === state.flag = false // trigger(state, 'flag') // → 找到 state.flag.dep = Set { effect } // → effect.scheduler 不存在，直接 effect.run() effect.run() // 1. cleanupEffect: 遍历 effect.deps = [state.flag.dep, state.a.dep] // → state.flag.dep.delete(effect) → state.flag.dep = Set { } // → state.a.dep.delete(effect) → state.a.dep = Set { } // → effect.deps = [] // 2. activeEffect = effect // 3. 执行 fn → 读 state.flag → track，state.flag.dep 再次加入 effect // 读 state.b → track，state.b.dep 加入 effect // 4. 恢复 // 结果： // state.flag.dep = Set { effect } // state.a.dep = Set { } ← 空！不再被 effect2 依赖 // state.b.dep = Set { effect } ← 新依赖 // effect.deps = [ state.flag.dep, state.b.dep ] ``` 现在 `state.a` 变了，这个 effect 不会被触发——因为它现在根本不读 `a` 了。 ### 3.3 不 clean 会怎样上面的例子，如果不清： ``` state.a.dep = Set { effect } ← 旧依赖还在 ``` 之后 `state.a` 每次修改都会触发这个 effect 重新执行，但它进去走 else 分支读 `state.b`，`state.a` 的值根本用不到。 **结果：多余的重复执行 + 依赖集合越来越大 = 性能和语义双重错误。**

图 3：分支依赖切换后，有 cleanup（左）会把 effect 从已不再读取的 state.a.dep 中移除，依赖精确；无 cleanup（右）则旧依赖残留，state.a 的修改仍会误触发 effect，导致多余执行与依赖集合膨胀。

--- ## 四、scheduler：trigger 之后的分叉口 ### 4.1 四种 effect 的区分——不是在运行时识别，而是在创建时配好 Vue 3 没有给 effect 加一个 type 字段，不存在 `if (effect.type === 'component')` 这种判断。区分四种 effect 的方式只有一个：**创建时配了不同的 scheduler。** ```javascript // 四种创建方式 // 1. 普通 effect new ReactiveEffect(fn) // scheduler = undefined // 2. 组件渲染 effect const e = new ReactiveEffect(componentUpdateFn) e.scheduler = () => queueJob(e) // 放异步队列 // 3. computed effect const e = new ReactiveEffect(getter) e.scheduler = () => { _dirty = true; trigger(...) } // 标记脏 // 4. watch effect const e = new ReactiveEffect(getter) e.scheduler = () => { callback(effect.run()) } // 读新值 + 调回调 ``` **trigger 的逻辑从来没变过：** ```javascript function trigger(target, key) { const dep = targetMap.get(target)?.get(key) if (!dep) return const effects = new Set(dep) // 拷贝一份，避免遍历时结构变化 effects.forEach(effect => { if (effect.scheduler) { effect.scheduler() // 有调度器就交给你 } else { effect.run() // 没调度器就直接跑 } }) } ``` **分叉点在创建 effect 的地方——四个 API，四种 scheduler。** ### 4.2 四种 scheduler 的完整对比 ``` trigger(target, key) │ ▼ 找到 dep，遍历其中的 effect │ ├─ 没有 scheduler（普通 effect） │ effect.run() │ 同步立即执行 fn │ 场景：用户直接调用 effect() │ 特点：改一次跑一次，没有任何中间层 │ ├─ 组件渲染 scheduler │ queueJob(effect) │ 把 effect 放进异步队列，去重，微任务批量执行 │ 场景：组件模板渲染 │ 特点：连续改三次，只渲染最后一次 │ ├─ computed scheduler │ _dirty = true │ trigger(computedRef, 'value') │ 只标记脏，不重新计算 │ 场景：computed │ 特点：等读取 value 时才懒计算，依赖不变直接返回缓存 │ └─ watch scheduler const newVal = effect.run() // 重新读值 const oldVal = ... callback(newVal, oldVal) // 调用户的回调场景：watch / watchEffect 特点：按 flush 策略决定执行时机 ```

图 4：trigger 找到 dep 后的决策分叉。所有 effect 都从同一条 trigger 路径进来，差别只在于创建时配的 scheduler：没有就同步 run，配了就交给 scheduler 决定执行时机与策略。

### 4.3 为什么调度器是灵魂没有这套调度系统： - 一个循环改 100 次数据，组件就渲染 100 次 - computed 每次 get 都要重新计算，没有缓存 - watch 的 `flush: 'post'` 根本没法实现（不知道什么时候组件渲染完） - 所有 effect 行为完全一样，无法区分使用场景 **Proxy + track/trigger 是骨架，scheduler 是血肉，cleanup 是免疫系统。** 三者缺一不可。 --- ## 五、一张完整结构图 ``` const targetMap = new WeakMap() // 全局依赖容器 let activeEffect = null // 全局上下文标记 // === 结构 === targetMap: target1 (WeakMap key) → Map { key1 → Set [ effectA, effectB ] ← dep (key1.dep) key2 → Set [ effectB, effectC ] ← dep (key2.dep) } target2 (WeakMap key) → Map { key3 → Set [ effectA, effectC ] ← dep (key3.dep) } effectB: fn: () => { ... } scheduler: () => { ... } （可选） deps: [ key1.dep, key2.dep ] ← 反向记录，指向它依赖的 dep // === 运行时流程 === effectB.run() ├─ cleanupEffect(this) │ for dep of this.deps: │ dep.delete(this) // 从旧 dep 中移除自己 │ this.deps = [] │ ├─ activeEffect = this // 标记 ├─ fn() │ └─ 读 target1.key1 → get → track(target1, key1) │ ├─ dep.add(this) // dep → effect │ └─ this.deps.push(dep) // effect → dep（双向记录完成） │ └─ activeEffect = null（或恢复外层） trigger(target1, key1) ├─ 找到 dep = Set [ effectA, effectB ] └─ 遍历 dep，每个 effect: ├─ 有 scheduler → scheduler() │ ├─ 组件：queueJob(effect) │ ├─ computed: dirty = true │ └─ watch: callback(run()) └─ 没有 scheduler → effect.run()（回到上面的 run 流程） ``` --- ## 六、常见误解清单 **1. “核心数据结构是双向链表”** 是 `WeakMap>>` 三层映射，加上 effect.deps 数组做反向记录。dep 是 Set，deps 是数组，不存在 prev/next 指针，不构成链表。 **2. “Vue 3 能识别 effect 类型”** 不是识别，是不同 API（`effect()`/`computed()`/`watch()`/组件渲染）在创建 effect 时，各自配了不同 scheduler。ReactiveEffect 类本身没有 type 字段。 **3. “watch 初始化会执行 callback”** 初始化执行的是 `effect.run()`，里面跑的是 getter（读数据建依赖），不是 callback。除非配了 `immediate: true`。 **4. “组件渲染会自动合并更新”** 不是自动，是 scheduler + queueJob 去重实现的。同一个 effect 多次进队列只留一份，微任务统一执行。 **5. “dep → effect 就够了，不需要 effect → deps”** 没有反向记录，cleanup 就没法做——你必须遍历所有响应式对象的所有 dep 去找哪个包含当前 effect，时间复杂度爆炸。 **6. “双向记录 = 双向链表”** “双向记录”指 dep 持有 effect 引用、effect 持有 dep 引用，是逻辑上的互相指向。“双向链表”是特定数据结构，节点有 prev/next 指针串联。两者完全不同。 --- ## 七、总结：三个设计咬合在一起 scheduler、cleanup、双向记录不是三个独立的功能，而是一套互相依赖的设计： - **双向记录**为 cleanup 提供了“从哪个 dep 删自己”的快速索引 - **cleanup** 确保每次执行后依赖都是精确的，不多不少 - **scheduler** 在 cleanup 和 track 之后决定“怎么执行、什么时候执行” 合在一起，回答了一个核心问题：**数据变了，怎么精确、高效地让该更新的东西更新——不多跑、不漏跑、不立刻跑。** 这三块搞明白了，Vue 3 响应式系统就不再有黑盒。代码量不大，设计却极其精妙。

zijieLeo 的树洞

nginx到底做了些啥？

为什么数据库里的密码是一串乱码？

props 变了，state 为什么没变？——一次线上分类过滤 BUG 的完整解剖

Vite、Turbopack 与开源的饭碗

如何挣脱呢？我也没答案

Vue 3 响应式核心：effect、scheduler、cleanup 与双向依赖设计

筛选文章

分类

标签

最近文章

统计

分类