在前端开发的江湖里Vue.js 凭借其简洁的API和强大的数据驱动Neng力，一度成为了无数开发者的心头好。尤其是Vue 2.x版本，虽然现在Vue 3Yi经遍地开花，但hen多老项目依然稳稳地跑在Vue 2上。面试的时候，面试官总喜欢问：“说说Vue的响应式原理吧？” hen多同学背得滚瓜烂熟：“Object.defineProperty发布订阅观察者模式……” 但Ru果再深挖一点，比如“发布订阅和观察者模式在Vue里到底是怎么共存的？” 或者 “数组的变化侦测为什么那么麻烦？”，可Neng不少人就开始支支吾吾了。

今天咱们不搞那些枯燥的学术定义，也不照本宣科地念源码。我想试着换个角度，带大家从发布订阅模式的设计思想出发，一步步拆解Vue 2.x是如何构建起这套精妙的响应式系统的。这不仅仅是为了应付面试，geng是为了理解那种“数据变，视图变”的魔法背后究竟藏着怎样的逻辑。

在正式动手写代码之前，咱们得先理清两个经常被混为一谈的概念：观察者模式和发布订阅模式。说实话，这俩兄弟长得确实挺像，dou是为了解决“一个对象的状态改变，通知其他依赖对象”的问题，但在Vue的源码里它们的分工可是相当明确的。

简单来说观察者模式比较直接，就像是你盯着老板，老板一动你就知道。而发布订阅模式则多了一个中间商——调度中心。就像你订阅了公众号，你不是直接盯着作者，而是通过微信这个平台。作者发文章，微信推给你。Vue 2的响应式系统，其实就是这两者的结合体，甚至Ke以说它把发布订阅模式玩出了花。

Vue 2之所以Neng实现响应式，离不开JavaScript提供的一个老牌API：Object.defineProperty。它的作用就是给对象的属性加一层“拦截”。我们Ke以把它想象成在属性的门口安了个监控摄像头。

当我们读取这个属性时就会触发 get 函数；当我们修改这个属性时就会触发 set 函数。这听起来hen简单，对吧？但正是这个简单的拦截，为后续的“依赖收集”和“派发geng新”提供了可Neng。

咱们先来kan一段Zui基础的代码，感受一下这种“劫持”的感觉：

let data = { message: 'Hello Vue' };
Object.defineProperty(data, 'message', {
  get {
    console.log;
    return val;
  },
  set {
    console.log;
    val = newVal;
  }
});

kan到了吗？只要我们操作 data.message，控制台就会有反应。这就是响应式的地基。但是光有监控还不够，我们得知道谁对这个属性感兴趣，谁需要在它变化的时候收到通知。这就轮到发布订阅模式登场了。

在上一节我们提到，发布订阅模式需要一个调度中心。在Vue的源码里这个调度中心有一个响亮的名字——Dep。你Ke以把它理解成一个专门用来存“订阅者”的小本本。

每一个响应式属性，dou会拥有这样一个 Dep 实例。当属性被读取时Dep 就会把当前的订阅者记下来；当属性被修改时Dep 就会翻出小本本，挨个通知这些订阅者：“嘿，数据变了赶紧geng新！”

咱们来改造一下上面的代码，引入 Dep 类：

class Dep {
  constructor {
    // 这个 subs 数组就是那个“小本本”，用来存所有的订阅者
    this.subs = ;
  }
  // 添加订阅者
  addSub {
    this.subs.push;
  }
  // 通知所有订阅者
  notify {
    this.subs.forEach);
  }
}

有了 Dep，我们的 Object.defineProperty 就Ke以变得geng智Neng了。但是这里有个问题：get 触发的时候，Dep 怎么知道当前的订阅者是谁呢？总不Neng让 Dep 满世界去找吧？这时候，我们需要一个全局的“中间人”变量，在Vue源码里它叫 Dep.target。

Ru果说 Dep 是调度员，那 Watcher 就是干活的苦力。在Vue里Watcher 代表的就是那些“依赖数据变化的实体”。比如一个组件的渲染函数，或者用户写的 watch 监听器。

Watcher 的工作流程其实挺有意思的。它在实例化的时候，会主动去把自己赋值给全局变量 Dep.target，然后去执行一下自己的 getter 方法。这一读不要紧，立马触发了数据的 get 拦截，数据的 Dep 就kan到了 Dep.target，心想：“原来是你小子在kan这个数据，那我得把你记下来。” 于是Dep 就把这个 Watcher 拉进了 subs 列表。

咱们来kankan Watcher 的简易实现：

class Watcher {
  constructor {
    this.vm = vm;
    this.getter = expOrFn; // 这里Ke以是一个函数，也Ke以是一个表达式解析函数
    this.cb = cb; // 回调函数
    this.value = this.get; // 初始化时主动触发依赖收集
  }
  get {
    // 关键步骤：把当前 Watcher 挂载到 Dep.target 上
    Dep.target = this;
    // 执行 getter，这会触发 data 的 get，从而完成依赖收集
    const value = this.getter.call;
    // 收集完了把全局变量清空，免得影响别人
    Dep.target = null;
    return value;
  }
  update {
    // 当数据变化时Dep 会调用这个方法
    const oldValue = this.value;
    this.value = this.get;
    this.cb.call;
  }
}

这一套组合拳下来Dep 和 Watcher 就建立起了联系。这就是Vue响应式Zui核心的依赖收集过程。是不是感觉比单纯的观察者模式要绕一点？但正是这种“主动出击”的收集方式，让VueNeng精准地知道谁依赖了谁。

讲完了对象，咱们得聊聊一个让人头疼的问题：数组。在JavaScript里数组也是对象，理论上也Neng用 Object.defineProperty 去监听。但是你监听数组的下标没啥大用，因为开发者经常用 pushpopsplice 这些方法去改变数组。这些方法并不会触发数组下标的 set 拦截，Vue 2也就无从得知数组变了。

怎么办？Vue 2的团队想出了一个“曲线救国”的办法：重写数组原型。

他们的思路是：既然拦截不到方法调用，那我就把数组的方法换掉！我们Ke以创建一个新对象，让它继承自 Array.prototype，然后在这个新对象里重写 pushpop 等方法。当我们把数组的 __proto__ 指向这个新对象时数组调用 push 其实就是在调用我们重写过的方法。

在重写的方法里我们除了执行原本的逻辑，还Neng顺便干点私活——手动触发依赖通知。这样，数组的变化也Neng被响应式系统捕捉到了。

const arrayProto = Array.prototype;
const arrayMethods = Object.create;
.forEach(method => {
  arrayMethods = function  {
    // 先执行原生的数组方法，保证功Neng正常
    const result = arrayProto.apply;
    // 这里的 this 就是数组实例，我们Ke以拿到它的 ob__ 
    const ob = this.__ob__;
    // 手动触发通知，告诉依赖这个数组的人：数组变了！
    ob.dep.notify;
    return result;
  };
});

当然这里还涉及到对新插入的元素也要进行响应式处理，这就需要递归调用 observe 方法了。虽然这种Zuo法有点“黑客”味道，而且无法监听通过下标直接赋值和数组长度修改的情况，但这Yi经是相当优雅的解决方案了。

Vue不仅帮我们自动管理视图渲染的 Watcher，还暴露了 $watch 这个API，允许我们自定义监听。geng有意思的是$watch 返回了一个 unwatch 函数，用来取消监听。

这就引出了一个geng深层次的问题：如何取消订阅？

既然 Dep 记录了 Watcher，那取消订阅的时候，Watcher 得告诉 Dep 把自己删掉。但是一个 Watcher 可Neng依赖了多个数据，也就是被多个 Dep 记录过。为了Neng彻底断绝关系，Watcher 自己也得有个小本本，记录下它dou订阅了哪些 Dep。

这就是所谓的双向订阅。在依赖收集阶段，Dep 把 Watcher 加进自己的 subs，同时 Watcher 也把 Dep 加进自己的 deps。当我们要取消监听时Watcher 就遍历自己的 deps，挨个通知它们：“别再理我了咱们分手吧。”

这种设计虽然增加了一点内存开销，但换来了极大的灵活性。它体现了Vue在处理复杂状态管理时的深思熟虑——不仅要Neng建立关系，还要Neng优雅地解除关系。

回顾一下Vue 2的响应式原理其实并不神秘。它通过 Object.defineProperty 拦截数据访问，利用 Dep 类作为消息代理中心，通过 Watcher 实现具体的业务逻辑geng新。对于数组这种特殊类型，又巧妙地利用原型链重写进行了兼容。

从设计模式的角度kan，Vue并没有死板地套用教科书上的定义，而是根据实际需求，将观察者模式和发布订阅模式进行了融合与变体。每一个属性dou是一个微型的发布者，而 Dep 则是连接发布者与订阅者的桥梁。这种“因地制宜”的工程思维，或许比源码本身geng值得我们学习。

虽然现在Vue 3Yi经用 Proxy 替代了 Object.defineProperty，解决了数组监听和性Neng上的诸多痛点，但理解Vue 2的这套机制，依然是我们掌握现代前端框架底层逻辑的必经之路。毕竟万变不离其宗，数据驱动视图的核心思想，始终未变。

希望这篇文章Neng帮你彻底理清Vue 2响应式的脉络。Ru果觉得写得还行，或者对你有点启发，不妨点个赞支持一下咱们下期继续深挖Vue 3的那些新花样！