文章

Vue 响应式系统源码级实战剖析

发表于 更新于
作者 deathwhispers
21 分钟阅读
Vue 响应式系统源码级实战剖析

很多后端同学学 Vue 的时候，容易把“响应式”理解成一句口号：数据变了，页面就会变。这个理解在入门阶段够用，但一到复杂页面，尤其是表格联动、批量编辑、动态表单、权限切换、性能优化场景，就会出现三个典型问题：

  1. 改了数据但是页面没按预期刷新。
  2. watch 链条变长后，副作用互相影响，线上偶发 bug 很难复现。
  3. 表面上代码可用，但一上数据量就卡顿，定位不到瓶颈。

要从“会写 Vue”进阶到“能稳定交付 Vue”，必须把响应式系统真正吃透。本文按后端工程师熟悉的方式，从数据结构、执行流程、调度策略、实战排障到性能优化，给你一个可落地的完整认知框架。

一、先用后端视角理解 Vue 响应式

把 Vue 响应式类比后端系统会更容易：

  • reactive/ref：相当于“被监管的数据对象”。
  • effect/render：相当于“订阅这些数据的消费者逻辑”。
  • track：相当于消费者注册依赖。
  • trigger：相当于发布变更通知。
  • scheduler：相当于异步任务队列和削峰机制。

这套机制本质就是一个高性能的发布订阅系统，只是它和渲染系统深度耦合，最终目标是“最小代价地更新 UI”。

二、核心数据结构：targetMap、dep、effect

响应式的关键不在语法，而在依赖图。

1. 依赖图结构

可以简化理解为：

1

WeakMap<target, Map<key, Set<effect>>>
  • target：被代理对象。
  • key：对象属性名。
  • effect：依赖该属性的副作用函数（渲染函数、computed getter、watch 回调等）。

用后端术语说，就是“对象-字段-订阅者”三级索引。

2. 为什么用 WeakMap

后端同学通常会问：为什么不是普通 Map？

因为 WeakMap 的 key 弱引用，不会阻止垃圾回收。组件卸载后，如果 target 不再可达，依赖映射可自动回收，避免内存泄漏。这个设计非常像缓存系统里的“自动淘汰机制”。

三、track 与 trigger：依赖收集和通知派发

1. track 发生在读取时

当 effect 执行并读取了响应式属性，Vue 会把“当前活跃 effect”收集进该属性的依赖集合。

伪代码：

1
2
3
4
5
6

function track(target, key) {
  if (!activeEffect) return
  const dep = getDep(target, key)
  dep.add(activeEffect)
  activeEffect.deps.push(dep)
}

重点：依赖是“读出来的”，不是“写出来的”。你不读取，就不会收集。

2. trigger 发生在写入时

当属性变更，Vue 根据 target+key 找到对应 dep，触发其中 effect。

1
2
3
4
5
6
7
8
9
10

function trigger(target, key) {
  const dep = getDep(target, key)
  for (const effect of dep) {
    if (effect.scheduler) {
      effect.scheduler()
    } else {
      effect.run()
    }
  }
}

重点：触发不是立即 DOM 更新，而是进入调度策略。

四、为什么你会遇到“改了不刷新”

这是后端同学最常见痛点，根因通常有四类。

1. 解构导致响应性丢失

1
2

const state = reactive({ count: 0 })
const { count } = state // count 脱离代理

后续 count 不再跟踪变更。正确做法是 toRef/toRefs。

2. 引用替换和对象变更混用

比如你在某些地方 state.user = newUser，另一些地方又在旧引用上改字段，依赖图会混乱，表现为局部不刷新或刷新时机异常。

3. shallow 与 deep 使用错误

shallowReactive/shallowRef 只跟踪第一层。如果你指望深层对象自动联动，结果一定不符合预期。

4. 在副作用里又制造副作用

例如 watch 回调里同步改另一个被同一 effect 依赖的状态，造成链式触发，最终看起来像“偶发不刷新”或者“连环刷新”。

五、ref、reactive、computed、watch 的职责边界

很多项目混乱就是因为四者边界不清。

1. ref：单值或独立引用状态

适合基础类型、DOM 引用、临时状态。你可以把它理解成“最小可追踪单元”。

2. reactive：结构化对象状态

适合表单、业务对象、页面聚合状态。优势是结构清晰，但要注意解构和替换风险。

3. computed：纯衍生状态

核心规则：

  • 必须是无副作用计算。
  • 输入不变，输出应稳定。
  • 不要在 computed 里发请求、写日志、改状态。

如果违反这个规则，调试体验会非常差。

4. watch/watchEffect：处理副作用

  • watch：你明确知道要监听谁。
  • watchEffect：让系统自动收集依赖。

工程上建议：

  • 业务关键链路优先 watch，可控性更高。
  • 临时联动逻辑可 watchEffect，但要尽快收敛。

六、调度器：为什么 Vue 不会每改一次都立刻重渲

Vue 的性能关键在“批处理”。

1. job 去重与微任务刷新

同一 tick 内多次状态变更会合并，避免重复渲染。调度器会把 job 放入队列，去重后在微任务阶段统一 flush。

这和后端消息消费里的“批量拉取+去重提交”非常像。

2. flush 时机

watch 支持 flush: 'pre' | 'post' | 'sync'：

  • pre：渲染前执行（默认）。
  • post：DOM 更新后执行，适合读取更新后的 DOM。
  • sync：同步执行，慎用，容易打破批处理优势。

很多“拿不到最新 DOM”的问题，本质是 flush 时机选错。

七、effectScope：复杂页面治理关键点

大页面里最怕副作用散落：多个 watch、多个定时器、多个事件监听，页面切换后清理不完整，内存和行为都可能泄漏。

effectScope 可以把一组副作用纳入同一作用域，统一 stop。

1
2
3
4
5
6
7

const scope = effectScope()
scope.run(() => {
  watch(...)
  watchEffect(...)
})

onUnmounted(() => scope.stop())

这相当于“事务边界”或“资源上下文”，是复杂模块非常实用的稳定性工具。

八、深度 watch 的成本与替代策略

watch(obj, cb, { deep: true }) 看起来方便，但在大对象上成本很高，因为它需要遍历和访问大量属性来建立依赖。

建议策略：

  1. 尽量监听精确字段，而不是整棵对象。
  2. 把大对象拆分为多个业务子对象。
  3. 对频繁变化字段做节流/防抖。
  4. 通过 computed 缩小观察面，再 watch computed 结果。

这相当于后端避免“全表扫描”，用“索引命中”思维做依赖管理。

九、一个真实场景：可编辑表格为什么容易抖动

场景：订单列表支持行内编辑，字段联动金额计算，支持批量修改。

常见错误实现：

  • 每一行多个 watchEffect。
  • 编辑时同时改原始数据和派生数据。
  • 计算逻辑分散在组件模板、watch、methods 三处。

结果：

  • 每次输入触发大量无效 effect。
  • 行间状态相互污染。
  • 撤销和重做几乎不可控。

更稳的做法：

  1. 原始数据单源：rawRows。
  2. 衍生计算集中到 computed：displayRows。
  3. 编辑缓冲区单独维护：draftMap。
  4. 提交时一次性合并并触发最小更新。
  5. 用 effectScope 管理当前页面的全部联动副作用。

这样设计后，依赖路径清晰、性能稳定、回归范围可控。

十、排障方法：如何定位响应式链路问题

给你一个可执行的排障顺序。

第一步：确认是否真的触发了写入

先看状态是否变化，不要先怀疑渲染。很多问题其实是赋值路径没走到。

第二步：确认读取是否在 effect 内发生

如果读取发生在 effect 外，依赖不会被收集。

第三步：确认是否发生了解构或脱代理

重点查 const { x } = reactiveObj 这类语句。

第四步：确认调度时机

如果你读 DOM，检查 watch flush 是否为 post。

第五步：确认是否有循环触发

看 watch 回调里是否反向修改了上游依赖。

这个流程和后端排查链路类似：先确认输入，再确认路由，再确认执行，再确认异步时序。

十一、响应式性能优化清单（可直接落地）

  1. 避免大对象 deep watch。
  2. 高频输入配合防抖，降低 trigger 频率。
  3. 列表渲染用稳定 key，避免不必要卸载重建。
  4. 把重计算逻辑放 computed，利用缓存。
  5. 复杂模块使用 effectScope 统一收口。
  6. 只在必要处使用 sync flush。
  7. 对超大静态对象使用 markRaw 或 shallow 策略。

十二、后端同学最容易忽略的一个点：副作用幂等

前端副作用和后端消息消费一样，也要追求幂等。watch 回调如果多次触发，结果应保持一致，不应重复发请求、重复弹窗、重复写状态。

建议你把副作用写成“可重入函数”，并对网络请求和 UI 通知做去重保护。这样即使触发时机发生变化，业务行为仍然稳定。

十三、从“语法掌握”到“工程掌控”

如果你只记 API，会在小 demo 里看起来很熟练；但只要业务复杂，问题就会集中爆发。真正的提升来自下面三件事：

  1. 理解依赖图和调度模型。
  2. 能把副作用边界收敛到可控范围。
  3. 形成可复用的排障与优化流程。

当你能解释“为什么触发、何时触发、触发多少次、如何控制触发成本”，你就已经不是“会写 Vue 页面”，而是具备了维护复杂前端系统的能力。

十四、建议练习题（进阶）

  1. 自己实现一个最小版 reactive + effect + track + trigger，不超过 100 行。
  2. 在你的项目里找一个 deep watch，改成精准 watch，并对比性能。
  3. 选一个复杂页面，用 effectScope 统一管理副作用并做一次内存观察。
  4. 给一个行内编辑表格加“编辑草稿层”，验证渲染次数是否下降。

做完这四步，响应式就不再是“黑盒”，而是你能主动设计和控制的工程能力。

十五、源码细节再下潜：cleanup 与依赖重建

很多人只知道 track 和 trigger，却忽略了另一个非常关键的点：每次 effect 重新执行前，Vue 会做依赖清理（cleanup），否则旧依赖会一直挂着，最终导致“明明不再读取这个字段却仍然被触发”的幽灵更新。

可以用后端来类比：一个消费者订阅了 TopicA 和 TopicB，后来业务逻辑变化只需要 TopicA。如果不取消 TopicB 订阅，系统会持续收到无效消息并浪费资源。Vue cleanup 做的就是这个“退订无效依赖”的动作。

这也是为什么条件分支切换时，响应式行为看起来会“自动纠偏”。例如：

1
2
3
4
5
6
7

watchEffect(() => {
  if (state.mode === 'A') {
    console.log(state.a)
  } else {
    console.log(state.b)
  }
})

当 mode 从 A 切到 B，下一轮执行会重新收集依赖，state.a 的依赖会被清掉，state.b 成为新依赖。理解这一点后，你就知道很多“分支切换后依然触发旧逻辑”的问题，往往是你在副作用外围做了额外闭包持有，而不是 Vue 响应式失效。

十六、调度优先级与组件更新队列

源码层还有一个常被忽略的事实：Vue 内部并不只是一条简单队列，而是有不同类型 job 的组织策略。组件更新、watch 回调、后置副作用的执行顺序，是经过设计的。

工程意义是什么？当你在一个复杂页面里同时做：

  1. 用户输入触发状态修改；
  2. watch 监听状态并做接口请求；
  3. 渲染完成后需要读取 DOM 尺寸；

如果你不区分调度时机，就会得到“偶发读取旧 DOM”“有时先发请求有时后发请求”的非确定行为。建议：

  • 数据联动类副作用使用默认 pre。
  • 依赖真实 DOM 的逻辑使用 post。
  • 极少数必须同步场景才用 sync，并明确性能代价。

把副作用按时序分层后，系统可预测性会明显提高。

十七、生产问题复盘模板：响应式专题

为了让团队长期受益，建议你把响应式问题复盘结构化。下面是一个可直接复制的模板：

  1. 现象：用户看到的异常是什么。
  2. 触发条件：什么操作组合会触发。
  3. 依赖链路：谁 track 了谁，谁 trigger 了谁。
  4. 调度时序：副作用在 pre/post/sync 哪个阶段执行。
  5. 根因分类：依赖遗漏、依赖污染、时序错误、循环触发、性能退化。
  6. 修复方案：代码层改动。
  7. 预防措施：lint 规则、编码规范、单测用例、监控埋点。

这套模板很像后端的故障复盘（RCA），能够把“靠个人经验排查”升级成“团队可复制能力”。

十八、团队规范建议：把响应式风险前置到评审

很多问题不是编码阶段出现，而是设计阶段埋雷。评审时建议增加以下检查项：

  1. 这个模块有哪些核心响应式状态？单一数据源是否明确？
  2. 哪些逻辑是衍生状态（computed），哪些是副作用（watch）？
  3. 是否存在 deep watch 大对象？
  4. 是否存在跨模块互相写状态的隐式耦合？
  5. 高频交互是否有防抖、节流和批处理策略？

把这 5 条前置到评审，能显著降低后期“怎么又抖了”的返工成本。

十九、结语补充：响应式能力是复杂前端的分水岭

Vue 初学阶段，大家都能“写出页面”；但在复杂系统中，能否稳定迭代，分水岭就是你对响应式机制的掌控程度。会 API 只是开始，真正的工程能力是：

  • 你能解释依赖为什么被收集；
  • 你能控制副作用何时执行；
  • 你能在复杂链路里收敛更新范围；
  • 你能把问题复盘成可复用规范。

当你具备这些能力，你在前端团队里扮演的就不再是“补代码的人”，而是“能守住复杂业务稳定性的工程师”。

Learning, Vue
Vue3 FrontendEngineering EngineeringPractice
本文由作者按照 CC BY 4.0 进行授权