1. 项目概述Watcher 软件架构的核心价值在软件开发的日常里我们经常需要处理一个经典问题如何让一个对象的状态变化能够自动、高效地通知到所有关心它的其他对象无论是前端框架里数据驱动的视图更新还是后端服务中配置热加载、缓存失效通知甚至是物联网设备的状态监控这个需求无处不在。而解决这个问题的核心设计模式就是观察者模式。今天我想和大家深入聊聊一个以“Watcher”为核心的软件架构设计。这不仅仅是实现一个简单的观察者模式而是一套从设计理念、核心组件到实战应用的完整体系。它关乎如何构建一个响应式、解耦且易于维护的系统。如果你正在设计一个需要实时数据同步、事件驱动的应用或者对Vue.js、React等框架的响应式原理感到好奇那么理解Watcher架构将为你打开一扇新的大门。简单来说Watcher架构的核心是建立一个“发布-订阅”的机制。系统中存在一个或多个“被观察者”Subject它们维护着一个“观察者”Watcher列表。当被观察者的状态发生改变时它会遍历这个列表逐个通知所有的Watcher“嘿我变了”。每个Watcher在接到通知后会执行预先定义好的回调逻辑比如更新UI、重新计算、或者触发下一个业务流程。这种架构将变化的源头和变化的响应方彻底解耦双方只需要约定好通知的“事件”或“数据路径”而无需知道对方的具体实现。这使得系统在面对需求变更时具有极强的灵活性和可扩展性。2. Watcher架构的核心设计思路与模式选型2.1 观察者模式 vs 发布-订阅模式细微之别与架构抉择很多人会把观察者模式和发布-订阅模式混为一谈但在构建健壮的Watcher架构时理解它们的区别至关重要。这直接决定了你核心通信模型的设计。观察者模式是一种更直接的耦合。被观察者Subject需要显式地维护一个观察者Observer对象的列表并在状态变化时直接调用观察者对象的更新方法如update()。这意味着Subject必须知道所有Observer的存在和接口。这是一种典型的“一对多”依赖关系但依赖关系是紧的。发布-订阅模式则引入了一个中间人——事件通道Event Channel 或 Event Bus。发布者Publisher不直接通知订阅者Subscriber而是向特定的事件通道发送消息发布事件。订阅者则向事件通道注册表明自己对某类事件感兴趣。当事件发生时由事件通道负责将消息分发给所有订阅者。这样发布者和订阅者完全不知道对方的存在实现了彻底的解耦。在Watcher架构的实践中我们通常采用发布-订阅模式的变体或思想来构建核心。为什么因为纯粹的观察者模式在大型复杂应用中会带来维护噩梦。想象一下一个核心数据对象需要被几十个不同的UI组件、服务模块监听如果它要直接管理这么多观察者其本身的代码会变得臃肿且增加或移除观察者的逻辑会散落在各处。而通过一个中心化或层级化的事件系统管理起来就清晰得多。注意像Vue 2中的响应式系统虽然我们常称之为“Watcher”但其内部实现更接近一个依赖收集的模型。defineProperty拦截属性的getter和setter在getter中收集依赖记录是哪个Watcher读取了我在setter中触发依赖通知通知所有收集到的Watcher更新。这可以看作是一种高度优化、与数据绑定深度集成的特殊发布-订阅实现而不是一个通用的、中心化的事件总线。2.2 核心组件抽象与职责划分一个完整的Watcher架构通常包含以下几个核心抽象理解它们各自的职责是设计的关键可观察对象Observable / Subject这是状态或数据的持有者。它的职责是提供方法让外部能够“观察”其内部特定部分的变化。在简单实现中它自己维护观察者列表在复杂系统中它可能只负责在变化时向事件总线发射一个信号。关键设计点在于如何定义“变化”是任意属性改变还是特定属性改变是深度变化嵌套对象内部变化还是浅变化观察者/监听器Watcher / Observer / Listener这是对变化做出响应的实体。它订阅或注册到某个可观察对象或特定事件上并提供一个回调函数。当关注的变化发生时这个回调函数会被执行。Watcher的设计需要考虑回调函数的上下文this是什么如何传递变化的具体信息新旧值Watcher的生命周期如何管理创建、激活、销毁调度中心/依赖收集器Scheduler / Dependency Collector这是架构的“大脑”尤其在追求性能的响应式系统中至关重要。它的职责包括依赖收集在Watcher执行其回调或求值函数的过程中自动追踪它访问了哪些Observable的属性并建立“Watcher 依赖于 这些属性”的关系。变化调度当Observable发生变化时不是立即执行所有关联Watcher的回调而是将它们标记为“待更新”dirty并放入一个队列中。异步更新在一个适当的时机例如下一个事件循环微任务中批量执行队列中所有Watcher的更新。这避免了同一个数据变化在同一个周期内触发多次重复计算和渲染是Vue等框架实现高性能更新的核心。事件通道/主题Event Channel / Topic在更通用的发布-订阅模型中这是消息传递的媒介。它根据事件类型主题来管理订阅者列表。发布者和订阅者通过事件名称或主题进行关联而不是直接引用对方。2.3 架构模式选型的实践考量选择哪种具体实现模式取决于你的应用场景前端UI框架如Vue首选依赖收集 异步队列调度模式。因为UI更新代价高需要最小化、批量化的更新操作。Watcher在这里通常与组件实例或计算属性绑定。后端配置热更新可能采用简单的观察者模式或事件总线。配置对象作为Subject各个服务模块作为Observer注册监听。当配置文件被修改并重新加载后Subject通知所有Observer各服务重新读取配置。此时对性能的极致要求不如前端高更注重可靠性和顺序。分布式系统事件通知必须采用发布-订阅模式并且事件通道本身可能是一个独立的消息中间件如Redis Pub/Sub、Kafka、RabbitMQ等。发布者和订阅者是不同的服务完全解耦通过中间件进行可靠的消息传递。浏览器环境中的自定义事件直接使用EventTargetAPIaddEventListener,dispatchEvent就是一种内置的发布-订阅实现。你可以创建自定义事件在任何DOM元素或自定义对象上进行派发和监听。3. 核心细节解析以响应式系统为例的深度实现为了让大家有最直观的感受我们以一个简化版但包含核心思想的响应式系统为例拆解其实现细节。这类似于Vue 2的核心原理能很好地诠释Watcher架构的精妙之处。3.1 可观察数据Observable的实现劫持的艺术我们要让一个普通对象变成可观察的核心方法是拦截其属性的读取和设置操作。在ES5环境下我们使用Object.defineProperty在ES6环境下可以使用Proxy。这里以defineProperty为例因为它更直观地展示了原理。// 依赖类每个可观察属性对应一个Dep实例用于管理订阅它的所有Watcher class Dep { constructor() { this.subs new Set(); // 使用Set避免重复添加同一个Watcher } depend() { // 依赖收集将当前正在执行的WatcherDep.target加入订阅列表 if (Dep.target) { this.subs.add(Dep.target); } } notify() { // 通知更新遍历所有订阅的Watcher调用其update方法 for (const sub of this.subs) { sub.update(); } } } // 全局唯一的指针指向当前正在计算的Watcher Dep.target null; function defineReactive(obj, key, val) { const dep new Dep(); // 为每个属性创建一个依赖管理器 // 递归处理值为对象的情况实现深度观察 observe(val); Object.defineProperty(obj, key, { enumerable: true, configurable: true, get: function reactiveGetter() { // 当属性被读取时进行依赖收集 dep.depend(); return val; }, set: function reactiveSetter(newVal) { if (newVal val) return; // 值未变化直接返回 val newVal; // 新值也需要变成可观察的 observe(newVal); // 值变化后通知所有依赖于此属性的Watcher dep.notify(); } }); } function observe(obj) { if (!obj || typeof obj ! object) return; // 遍历对象所有属性将其定义为可观察的 Object.keys(obj).forEach(key { defineReactive(obj, key, obj[key]); }); }关键点解析每个属性一个Dep这是高效更新的基础。只有真正被Watcher用到的属性才会建立依赖关系。如果Watcher没有读取obj.a那么obj.a的变化就不会通知到这个Watcher。Dep.target全局变量这是一个巧妙的设计。它像一个“电话线”在Watcher执行其求值函数前将自己Dep.target设置为自身。这样在求值函数内部任何被访问的可观察属性的getter被触发时都能通过Dep.target知道是“谁”在读取它从而完成依赖收集。深度观察在setter和observe函数中递归处理对象确保了嵌套对象内部的变化也能被捕获和通知。3.2 观察者Watcher的实现连接数据与行为的桥梁Watcher是主动发起依赖收集的实体。它接受一个求值函数或表达式和一个回调函数。当它首次执行或依赖的数据变化后会重新求值并执行回调。class Watcher { constructor(vm, expOrFn, cb, options) { this.vm vm; // 上下文对象通常是一个Vue组件实例 this.cb cb; // 数据变化后的回调函数 this.deps new Set(); // 记录这个Watcher订阅了哪些Dep用于后续清理 this.depIds new Set(); // Dep id的Set用于去重 this.getter typeof expOrFn function ? expOrFn : () vm[expOrFn]; // 支持函数或表达式字符串 // 懒执行模式如computed属性 this.lazy options options.lazy; this.dirty this.lazy; // 对于懒执行Watcher初始为dirty状态 this.value this.lazy ? undefined : this.get(); // 立即求值非懒执行模式下 } get() { // 关键步骤将Dep.target指向当前Watcher实例 pushTarget(this); let value; try { // 执行求值函数这会触发其中所有依赖数据的getter从而完成依赖收集 value this.getter.call(this.vm); } finally { // 依赖收集完成恢复上一个Watcher因为可能存在嵌套Watcher如computed中访问另一个computed popTarget(); // 这里可以清理不再依赖的旧Dep优化步骤略 } return value; } update() { // 当依赖的数据变化时Dep会调用此方法 if (this.lazy) { // 如果是懒执行Watcher如computed只标记为dirty下次访问时再重新计算 this.dirty true; } else { // 否则将Watcher推入异步更新队列 queueWatcher(this); } } run() { // 在更新队列中被调度执行 const value this.get(); // 获取新值 const oldValue this.value; // 旧值 this.value value; // 执行用户回调传入新值和旧值 this.cb.call(this.vm, value, oldValue); } evaluate() { // 专门用于懒执行Watcher的求值 this.value this.get(); this.dirty false; // 计算完毕标记为干净 } depend() { // 让所有当前Watcher依赖的Dep也收集上层Watcher用于computed属性被模板依赖时 for (const dep of this.deps) { dep.depend(); } } } // 模拟一个简单的栈来管理Dep.target const targetStack []; function pushTarget(target) { if (Dep.target) targetStack.push(Dep.target); Dep.target target; } function popTarget() { Dep.target targetStack.pop(); }实操心得pushTarget/popTarget栈管理这是支持嵌套依赖例如一个计算属性Watcher在其求值函数中访问了另一个计算属性的关键。必须确保依赖收集的上下文正确。dirty标志位对于计算属性computed这类懒执行Watcherdirty机制避免了不必要的重复计算。只有当其依赖的数据变化后它才被标记为“脏”下次访问时才会重新计算。这是性能优化的重要一环。依赖清理一个完善的Watcher还需要在销毁时从所有它订阅的Dep的subs列表中移除自己防止内存泄漏。上述示例中this.deps就是为此记录的。3.3 异步更新队列Scheduler性能优化的核心如果每次数据变化都同步执行Watcher回调那么在一次事件循环中频繁修改多个数据会导致大量重复计算和可能的多余渲染如UI更新。异步更新队列将变化“缓冲”起来一次性处理。const queue []; // 待更新的Watcher队列 let has {}; // 用于Watcher去重基于其唯一id let waiting false; // 是否已开始下一轮的刷新 let flushing false; // 是否正在刷新队列 let index 0; function queueWatcher(watcher) { const id watcher.id; // 假设每个Watcher有唯一id if (has[id] null) { has[id] true; if (!flushing) { // 如果不在刷新中直接入队 queue.push(watcher); } else { // 如果正在刷新需要按id顺序插入到正确位置保证执行顺序 let i queue.length - 1; while (i index queue[i].id watcher.id) { i--; } queue.splice(i 1, 0, watcher); } // 启动下一轮的队列刷新 if (!waiting) { waiting true; nextTick(flushSchedulerQueue); } } } function flushSchedulerQueue() { flushing true; // 队列排序保证1.组件更新从父到子2.用户Watcher在渲染Watcher之前执行3.如果一个组件在父组件Watcher运行期间被销毁它的Watcher可以被跳过。 queue.sort((a, b) a.id - b.id); for (index 0; index queue.length; index) { const watcher queue[index]; // 执行前再次检查因为可能在排队过程中watcher被销毁了 if (watcher.before) { watcher.before(); // 调用beforeUpdate钩子如Vue中的 } has[watcher.id] null; // 清除标记 watcher.run(); // 执行更新 } // 队列刷新完毕重置状态 resetSchedulerState(); } function resetSchedulerState() { index queue.length 0; has {}; waiting flushing false; } // nextTick的实现优先使用微任务(Promise/MutationObserver)降级到宏任务(setImmediate/setTimeout) const callbacks []; let pending false; function nextTick(cb, ctx) { callbacks.push(() { try { cb.call(ctx); } catch (e) { console.error(nextTick error:, e); } }); if (!pending) { pending true; // 这里简化实现实际环境需做能力检测 Promise.resolve().then(flushCallbacks); // 或者降级方案setTimeout(flushCallbacks, 0); } } function flushCallbacks() { pending false; const copies callbacks.slice(0); callbacks.length 0; for (const fn of copies) { fn(); } }为什么需要异步队列和排序去重同一个Watcher可能在同一个事件循环中被多次触发例如一个计算属性依赖了A和BA和B在同一个函数中被连续修改。队列机制确保它只被执行一次。批处理与性能将多个数据变更导致的更新合并到一次UI渲染或计算中大大提升性能。执行顺序保证确保父组件的更新在子组件之前因为父组件Watcher的id更小这保证了数据流自上而下的稳定性避免子组件基于可能过期的父组件状态进行更新。4. 实战应用构建一个简易的响应式状态管理模块理解了核心原理后我们可以动手构建一个简易的、独立于任何框架的响应式状态管理模块。这个模块可以用于中小型项目实现跨组件或模块的状态共享与响应。4.1 模块设计与API定义我们的目标API设计如下import { reactive, watch, computed } from ./my-reactive; // 1. 创建响应式对象 const state reactive({ count: 0, user: { name: Alice } }); // 2. 监听状态变化 const stopWatch watch( () state.count, // 监听来源可以是一个函数或一个getter函数 (newVal, oldVal) { console.log(count changed from ${oldVal} to ${newVal}); }, { immediate: true } // 选项立即执行一次 ); // 3. 创建计算属性 const doubleCount computed(() state.count * 2); console.log(doubleCount.value); // 访问.value获取值且自动追踪依赖 // 4. 修改状态触发响应 state.count; // 控制台输出: count changed from 0 to 1 // doubleCount.value 自动变为 2 // 5. 停止监听 stopWatch();4.2 核心模块实现我们将之前拆解的Dep,Watcher, 响应式化方法整合起来并增加watch和computed函数。// dep.js class Dep { constructor() { this.subs new Set(); } depend() { if (Dep.target) { this.subs.add(Dep.target); Dep.target.addDep(this); // 让Watcher也记录这个Dep } } notify() { for (const sub of this.subs) { sub.update(); } } } Dep.target null; const targetStack []; function pushTarget(target) { /* 同上 */ } function popTarget() { /* 同上 */ } // observer.js function defineReactive(obj, key, val) { const dep new Dep(); observe(val); // 递归观察 Object.defineProperty(obj, key, { get() { dep.depend(); return val; }, set(newVal) { if (newVal val) return; val newVal; observe(newVal); dep.notify(); } }); } function observe(obj) { if (!obj || typeof obj ! object) return; // 避免重复观察 if (obj.__ob__) return; Object.defineProperty(obj, __ob__, { value: new Observer(obj), enumerable: false, writable: true, configurable: true }); } class Observer { constructor(value) { this.value value; this.walk(value); } walk(obj) { Object.keys(obj).forEach(key { defineReactive(obj, key, obj[key]); }); } } // watcher.js let uid 0; class Watcher { constructor(vm, expOrFn, cb, options {}) { this.id uid; this.vm vm; this.cb cb; this.deps new Set(); this.depIds new Set(); this.getter typeof expOrFn function ? expOrFn : () vm[expOrFn]; this.lazy !!options.lazy; this.dirty this.lazy; this.immediate !!options.immediate; if (typeof expOrFn function !this.lazy) { // 对于非懒执行的watch先求值一次触发依赖收集 this.value this.get(); } else { this.value undefined; } if (this.immediate) { this.cb.call(this.vm, this.value, undefined); } } get() { pushTarget(this); let value; try { value this.getter.call(this.vm); } finally { popTarget(); this.cleanupDeps(); // 清理旧依赖简化实现略 } return value; } addDep(dep) { const id dep.id || (dep.id uid); // 给Dep也加个id if (!this.depIds.has(id)) { this.depIds.add(id); this.deps.add(dep); } } update() { if (this.lazy) { this.dirty true; } else { queueWatcher(this); } } run() { const value this.get(); const oldValue this.value; this.value value; this.cb.call(this.vm, value, oldValue); } evaluate() { this.value this.get(); this.dirty false; } depend() { for (const dep of this.deps) { dep.depend(); } } teardown() { // 从所有依赖的Dep中移除自己 for (const dep of this.deps) { dep.subs.delete(this); } this.deps.clear(); this.depIds.clear(); } } // scheduler.js (queueWatcher, nextTick等同上略) // index.js - 主出口文件 import { observe } from ./observer.js; import { Watcher } from ./watcher.js; import { queueWatcher } from ./scheduler.js; export function reactive(obj) { observe(obj); return obj; } export function watch(source, cb, options {}) { const vm this || {}; // 提供上下文可以是任意对象 let getter; if (typeof source function) { getter source; } else { // 简单处理支持响应式对象的属性路径字符串如 user.name getter () { let val vm; const paths source.split(.); for (const path of paths) { val val[path]; } return val; }; } const watcher new Watcher(vm, getter, cb, { lazy: false, ...options }); // 返回一个停止监听的函数 return () watcher.teardown(); } export function computed(getter) { const vm this || {}; let computedWatcher null; let computedValue; const result {}; Object.defineProperty(result, value, { get() { if (!computedWatcher) { // 懒创建Watcher computedWatcher new Watcher(vm, getter, null, { lazy: true }); } if (computedWatcher.dirty) { computedWatcher.evaluate(); } // 关键让上层Watcher比如模板渲染Watcher收集到这个计算属性的依赖 if (Dep.target) { computedWatcher.depend(); } return computedWatcher.value; } }); return result; }注意事项这是一个极度简化的教学版本缺少很多边界条件处理如数组的响应式、新增属性的响应式、$set/$delete 等方法。在实际项目中应优先使用成熟的库如 Vue 3 的vue/reactivity包它提供了独立、强大的响应式系统。computed的实现中depend()的调用是关键。它确保了当计算属性在另一个Watcher例如渲染函数中被读取时上层的Watcher能订阅到这个计算属性所依赖的所有原始数据。否则原始数据变化时上层Watcher不会收到通知。5. 常见问题、排查技巧与性能优化5.1 典型错误与排查问题一回调函数中访问了未定义的属性如网络热词中的错误错误信息Error in callback for watcher ()t.position: TypeError: Cannot read properties of undefined (reading lat)原因分析Watcher的回调函数或求值函数()t.position在执行时试图访问t.position但此时t是undefined。这通常发生在异步操作中比如你监听了一个对象但在该对象被正确赋值例如从API获取数据之前Watcher已经被触发可能因为immediate: true或其他依赖数据先变了。排查步骤检查回调函数在回调函数开始处添加console.log(Watcher triggered with:, t)确认t的状态。检查依赖数据初始化确保被观察的数据在Watcher首次运行前已被正确初始化。对于可能为undefined的嵌套属性考虑使用可选链操作符?.进行安全访问() t?.position?.lat。审查immediate选项如果设置了immediate: true确保回调函数能处理数据初始为undefined的情况。审查数据更新时机检查是哪个操作修改了依赖数据导致Watcher被触发。可能是某个异步回调如setTimeout, Promise修改了数据。问题二内存泄漏原因Watcher被创建后例如在组件中监听全局事件总线在组件销毁时没有正确移除teardown。导致被观察对象或事件总线一直持有对已销毁组件Watcher的引用使其无法被垃圾回收。解决方案严格遵守生命周期。在Vue组件中在beforeUnmount或unmounted钩子中手动调用watch返回的停止函数。如果自己实现状态管理确保Watcher持有对依赖的引用同时提供显式的销毁接口。问题三循环更新或无限递归原因Watcher A 的回调修改了数据触发了 Watcher B而 Watcher B 的回调又修改了数据再次触发 Watcher A形成死循环。排查在开发环境中可以给Watcher添加深度限制计数器或使用Set记录当前正在执行的Watcher栈如果发现同一个Watcher在单次更新循环中被重复触发则抛出警告。预防设计数据流时应避免双向依赖。在Watcher回调中修改其他被观察数据时要格外小心。5.2 性能优化实践合理使用计算属性computed vs 侦听器watchcomputed用于派生状态基于响应式数据计算出新的值。它有缓存只有依赖变化时才重新计算。适合模板中使用的复杂表达式。watch用于执行副作用如异步请求、DOM操作、打印日志。它无缓存每次依赖变化都会执行。适合数据变化后需要执行特定动作的场景。黄金法则能用computed尽量用computed因为它自动缓存性能更优。避免深度监听大型对象watch(obj, callback, { deep: true })会递归遍历对象的所有属性为其建立响应式绑定性能开销大。如果只需要监听某个特定嵌套属性使用函数返回该属性路径watch(() obj.a.b.c, callback)。异步更新队列的妙用利用nextTick确保在DOM更新后再执行某些操作。例如在修改数据后需要操作基于新数据渲染的DOM元素可以将操作放在nextTick回调中。惰性观察对于不需要立即计算或监听的数据使用lazy选项或手动控制Watcher的激活时机。使用Object.freeze()冻结纯展示数据如果你有一个巨大的、只用于展示且永远不会变的数据列表使用Object.freeze()冻结它。Vue会跳过对冻结对象的响应式转换过程这能显著提升初始化性能。5.3 调试技巧自定义Dep和Watcher在开发版本中可以给Dep和Watcher类添加调试标识并在notify和update时打印日志清晰看到数据流和触发链。利用Vue Devtools如果基于Vue开发Vue Devtools是神器。可以查看组件树、状态、事件以及追踪数据变化的时空轨迹。最小化复现当遇到复杂的Watcher相关bug时尝试创建一个最小的、可复现的示例。剥离无关的业务逻辑往往能更快定位到核心问题。Watcher架构是构建现代响应式应用的基石。从简单的UI绑定到复杂的分布式事件系统其核心思想——解耦变化与响应——贯穿始终。理解其原理不仅能让你更好地使用Vue、React等框架更能让你在设计和构建自己的系统时多一件趁手的利器。记住好的架构不是堆砌模式而是用恰当的方式解决具体的问题。Watcher模式就是为解决“变化通知”这个具体问题而生的优雅方案。
