“Vue 2 的响应式是怎么实现的？”

本文用一张流程图 + 四段源码级剖析，带你走完 Observer → Dep → Watcher → Scheduler 的完整链路。

一、为什么需要响应式

在传统命令式框架中，开发者必须手动调用 DOM API 更新视图，逻辑与渲染耦合。Vue 2 的核心目标是数据驱动——当对象或属性变化时，视图自动重绘。实现这一目标的底层机制就是响应式系统。

二、四大核心角色

1.Observer

进入组件生命周期 beforeCreate → created 之间，Vue 会递归遍历 data 中的每个属性，通过 Object.defineProperty 重写 getter/setter：

• getter：收集依赖（记录谁在读我）；
• setter：派发更新（通知所有依赖我“我变了”）。

动态增删属性无法被劫持，因此需要 vm.$set / vm.$delete 手动触发响应式。

数组则通过重写原型链方法（push、pop、splice 等）实现拦截，确保“数组内容变化”也能被观测。

2.Dep
每个响应式对象的每个属性都会对应一个 Dep 实例。它只做两件事：

• 记录依赖（谁在读取我）；
• 触发更新（属性变化时通知所有依赖）。

当改变某个属性时，它会派发更新：那些用我的人听好了，我变了。

3.Watcher
当 render 函数执行时，Vue 不会直接运行它，而是交给一个 Watcher。Watcher 的职责：

• 运行函数前，把自己设为全局变量；
• 函数执行过程中，任何响应式数据的 getter 都会把当前 Watcher 记录到对应 Dep；
• 当 Dep 触发更新时，Watcher 重新运行函数（通常是 render）。

每个组件实例至少有一个渲染 Watcher，确保数据变化 → 组件重新渲染。

4.Scheduler
如果同一轮事件循环内多次修改响应式数据，Watcher 会被多次标记为“待更新”。
Scheduler 会把这些 Watcher 放入微任务队列（通过 Promise.then 实现 nextTick），同一个 Watcher 只出现一次，从而避免不必要的重复渲染，实现批量异步更新。

三、整体数据流回顾

1. 组件初始化 → Observer 劫持属性 → 建立 Dep 与 Watcher 关联
2. 用户交互触发 setter → Dep 通知 Watcher → Watcher 加入 Scheduler 队列
3. 微任务阶段统一 flush 队列 → 组件 render 重新执行 → 虚拟 DOM diff → 最小化 DOM 更新