前言

为了更好的做解释，我会调整源码中的接口、类型、函数等声明顺序，并会增加一些注释方便阅读

在上一章中，我们介绍了ref，如果仔细看过，想必对ref应该已经了如指掌了。如果还没有，或着忘记了....可以先回顾一下上篇文章。

阅读本篇文章需要的前置知识有：

Reactive

reactive这个文件代码其实不多，100 来行，很多逻辑其实是在handlers跟effect中。我们先看这个文件的引入：

外部引用

import {
  isObject, // 判断是否是对象
  toTypeString // 获取数据的类型名称
} from '@vue/shared'
// 此处的handles最终会传递给Proxy(target, handle)的第二个参数
import {
  mutableHandlers, // 可变数据代理处理
  readonlyHandlers // 只读(不可变)数据代理处理
} from './baseHandlers'

// collections 指 Set, Map, WeakMap, WeakSet
import {
  mutableCollectionHandlers, // 可变集合数据代理处理
  readonlyCollectionHandlers // 只读集合数据代理处理
} from './collectionHandlers'

// 上篇文章中说了半天的泛型类型
import { UnwrapRef } from './ref'
// 看过单测篇的话，应该知道这个是被effect执行后返回的监听函数的类型
import { ReactiveEffect } from './effect'

所以不用怕，很多只是引了简单的工具方法跟类型，真正跟外部函数有关联的就是几个handlers。

类型与常量

再来看类型的声明跟变量的声明，先看注释很多的targetMap。

// The main WeakMap that stores {target -> key -> dep} connections.
// Conceptually, it's easier to think of a dependency as a Dep class
// which maintains a Set of subscribers, but we simply store them as
// raw Sets to reduce memory overhead.
export type Dep = Set<ReactiveEffect>
export type KeyToDepMap = Map<string | symbol, Dep>
// 翻译自上述英文：利用WeakMap是为了更好的减少内存开销。
export const targetMap = new WeakMap<any, KeyToDepMap>()

traget的意思就是Proxy(target, handle)函数的第一个入参，也就是我们想转成响应式数据的原始数据。但这个KeyToDepMap其实看不明白具体是怎么样的映射。先放着，等到我们真正使用它时，再来看。

继续往下看，是一堆常量的声明。

// raw这个单词在ref篇我们见过，它在这个库的含义是，原始数据
// WeakMaps that store {raw <-> observed} pairs.
const rawToReactive = new WeakMap<any, any>()
const reactiveToRaw = new WeakMap<any, any>()
const rawToReadonly = new WeakMap<any, any>()
const readonlyToRaw = new WeakMap<any, any>()

// WeakSets for values that are marked readonly or non-reactive during
// observable creation.
const readonlyValues = new WeakSet<any>()
const nonReactiveValues = new WeakSet<any>()

// 集合类型
const collectionTypes = new Set<Function>([Set, Map, WeakMap, WeakSet])
// 用于正则判断是否符合可观察数据，object + array + collectionTypes
const observableValueRE = /^\[object (?:Object|Array|Map|Set|WeakMap|WeakSet)\]$/

如果读过单测篇(reactive 的第 8、9、10 个单测)，可能会记得之前说过，内部需要两个WeakMap来实现原始数据跟响应数据的双向映射。明显的rawToReactive跟reactiveToRaw就是这两个WeakMap。rawToReadonly跟readonlyToRaw顾名思义的就是映射原始数据跟只读的响应数据的两个WeakMap。

readonlyValues跟nonReactiveValues根据注释以及之前单测篇的记忆，可能是跟markNonReactive跟markReadonly(这个单测篇没讲到)有关。猜测是用来存储用这两个 api 构建的数据，具体也可以后面再看。

collectionTypes跟observableValueRE看注释即可。

工具函数

在真正看reactive之前，我们把本文件内部的一些工具方案先过一遍，这样看源码时就不会东跳西跳比较乱。这部分比较简单，简单瞄两眼就好了。

// 数据是否可观察
const canObserve = (value: any): boolean => {
  return (
    // 整个vue3库都没搜到_isVue的逻辑，猜测是vue组件，不影响本库阅读
    !value._isVue &&
    // 虚拟dom的节点不可观察
    !value._isVNode &&
    // 属于可观察的数据类型
    observableValueRE.test(toTypeString(value)) &&
    // 该集合中存储的数据不可观察
    !nonReactiveValues.has(value)
  )
}

// 如果reactiveToRaw或readonlyToRaw中存在该数据了，说明就是响应式数据
export function isReactive(value: any): boolean {
  return reactiveToRaw.has(value) || readonlyToRaw.has(value)
}

// 判断是否是只读的响应式数据
export function isReadonly(value: any): boolean {
  return readonlyToRaw.has(value)
}

// 将响应式数据转为原始数据，如果不是响应数据，则返回源数据
export function toRaw<T>(observed: T): T {
  return reactiveToRaw.get(observed) || readonlyToRaw.get(observed) || observed
}

// 传递数据，将其添加到只读数据集合中
// 注意readonlyValues是个WeakSet，利用set的元素唯一性，可以避免重复添加
export function markReadonly<T>(value: T): T {
  readonlyValues.add(value)
  return value
}

// 传递数据，将其添加至不可响应数据集合中
export function markNonReactive<T>(value: T): T {
  nonReactiveValues.add(value)
  return value
}

核心实现

上述的代码都是佐料，下面看本文件的核心代码，首先看reactive跟readonly函数

// 函数类型声明，接受一个对象，返回不会深度嵌套的Ref数据
export function reactive<T extends object>(target: T): UnwrapNestedRefs<T>
// 函数实现
export function reactive(target: object) {
  // if trying to observe a readonly proxy, return the readonly version.
  // 如果传递的是一个只读响应式数据，则直接返回，这里其实可以直接用isReadonly
  if (readonlyToRaw.has(target)) {
    return target
  }
  // target is explicitly marked as readonly by user
  // 如果是被用户标记的只读数据，那通过readonly函数去封装
  if (readonlyValues.has(target)) {
    return readonly(target)
  }

  // 到这一步的target，可以保证为非只读数据

  // 通过该方法，创建响应式对象数据
  return createReactiveObject(
    target, // 原始数据
    rawToReactive, // 原始数据 -> 响应式数据映射
    reactiveToRaw, // 响应式数据 -> 原始数据映射
    mutableHandlers, // 可变数据的代理劫持方法
    mutableCollectionHandlers // 可变集合数据的代理劫持方法
  )
}

// 函数声明+实现，接受一个对象，返回一个只读的响应式数据。
export function readonly<T extends object>(
  target: T
): Readonly<UnwrapNestedRefs<T>> {
  // value is a mutable observable, retrieve its original and return
  // a readonly version.
  // 如果本身是响应式数据，获取其原始数据，并将target入参赋值为原始数据
  if (reactiveToRaw.has(target)) {
    target = reactiveToRaw.get(target)
  }
  // 创建响应式数据
  return createReactiveObject(
    target,
    rawToReadonly,
    readonlyToRaw,
    readonlyHandlers,
    readonlyCollectionHandlers
  )
}

两个方法代码其实很简单，主要逻辑都封装到了createReactiveObject，两个方法的主要作用是：

透传给createReactiveObject相应地的代理数据与响应式数据的双向映射 map。
reactive会做readonly的相关校验，反之readonly方法也是。

下面继续看：

function createReactiveObject(
  target: any,
  toProxy: WeakMap<any, any>,
  toRaw: WeakMap<any, any>,
  baseHandlers: ProxyHandler<any>,
  collectionHandlers: ProxyHandler<any>
) {
  // 不是一个对象，直接返回原始数据，在开发环境下会打警告
  if (!isObject(target)) {
    if (__DEV__) {
      console.warn(`value cannot be made reactive: ${String(target)}`)
    }
    return target
  }
  // 通过原始数据 -> 响应数据的映射，获取响应数据
  let observed = toProxy.get(target)
  // target already has corresponding Proxy
  // 如果原始数据已经是响应式数据，则直接返回此响应数据
  if (observed !== void 0) {
    return observed
  }
  // target is already a Proxy
  // 如果原始数据本身就是个响应数据了，直接返回自身
  if (toRaw.has(target)) {
    return target
  }
  // only a whitelist of value types can be observed.
  // 如果是不可观察的对象，则直接返回原对象
  if (!canObserve(target)) {
    return target
  }
  // 集合数据与(对象/数组) 两种数据的代理处理方式不同。
  const handlers = collectionTypes.has(target.constructor)
    ? collectionHandlers
    : baseHandlers
  // 声明一个代理对象，也即是响应式数据
  observed = new Proxy(target, handlers)
  // 设置好原始数据与响应式数据的双向映射
  toProxy.set(target, observed)
  toRaw.set(observed, target)

  // 在这里用到了targetMap，但是它的value值存放什么我们依旧不知道
  if (!targetMap.has(target)) {
    targetMap.set(target, new Map())
  }
  return observed
}

我们可以看到一些细节：

如果传递的是非对象，只是开发环境报警告，并不会导致异常。这是因为生产环境极其复杂，由于 js 是一门动态语言，如果直接报错，必定直接影响各类线上应用。在这只是返回了原始数据，失去了响应性，但不会导致真实页面异常。
这个方法基本没有 TS 类型了。

reactive文件其实非常通俗易懂，看完以后，我们心中只有 2 个问题：

baseHandlers，collectionHandlers的具体实现以及为什么要区分？
targetMap到底是啥？

当然我们知道handlers肯定是做依赖收集跟响应触发的。那我们就先看着两个文件。

baseHandles

打开此文件，同样先看外部引用:

// 这些我们已经了解了
import { reactive, readonly, toRaw } from './reactive'
import { isRef } from './ref'
// 这些就是些工具方法，hasOwn 意为对象是否拥有某数据
import { isObject, hasOwn, isSymbol } from '@vue/shared'
// 这里定义了操作数据的行为枚举
import { OperationTypes } from './operations'
// LOCKED：global immutability lock
// 一个全局用来判断是否数据是不可变的开关
import { LOCKED } from './lock'
// 收集依赖跟触发监听函数的两个方法
import { track, trigger } from './effect'

只有track跟trigger的内部实现我们不知道，其他的要么已经了解了，要么点开看看一眼就明白。

然后是一个代表 JS 内部语言行为的描述符的集合，不明白的可以看相应MDN。具体怎么使用可以后面再看。

const builtInSymbols = new Set(
  Object.getOwnPropertyNames(Symbol)
    .map(key => Symbol[key])
    .filter(key => typeof key === 'symbol')
)

然后会发现下面就百来行代码，我们找到reactive中引用的mutableHandlers、readonlyHandlers。我们先看简单的mutableHandlers：

export const mutableHandlers: ProxyHandler<any> = {
  get: createGetter(false),
  set,
  deleteProperty,
  has,
  ownKeys
}

这是一个ProxyHandle，关于Proxy如果忘记了，记得再看一遍MDN。

然后终于到了整个响应式系统最关键的地方了，这五个traps：get,set,deleteProperty,has,ownKeys。当然Proxy能实现的trap并不仅是这五个。其中defineProperty跟getOwnPropertyDescriptor两个trap不涉及响应式，不需要劫持。还有一个enumerate已经被废弃。enumerate原本会劫持for-in的操作的，那你会想，那这个废弃了，我们的for-in怎么办？放心，它还是走到ownKeys这个trap，进而触发我们的监听函数的。

说远了，回到代码中，我们从负责收集依赖的get看。这个trap是通过createGetter函数生成，那我们来看看它。

get

createGetter接受一个入参：isReadonly。那自然在readonlyHandlers中就是传true。

// 入参只有一个是否只读
function createGetter(isReadonly: boolean) {
  // 关于proxy的get，请阅读：https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler/get
  // receiver即是被创建出来的代理对象
  return function get(target: any, key: string | symbol, receiver: any) {
    // 如果还不了解Reflect，建议先阅读它的文档：https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Reflect
    // 获取原始数据的相应值
    const res = Reflect.get(target, key, receiver)
    // 如果是js的内置方法，不做依赖收集
    if (isSymbol(key) && builtInSymbols.has(key)) {
      return res
    }
    // 如果是Ref类型数据，说明已经被收集过依赖，不做依赖收集，直接返回其value值。
    if (isRef(res)) {
      return res.value
    }
    // 收集依赖
    track(target, OperationTypes.GET, key)
    // 通过get获取的值不是对象的话，则直接返回即可
    // 否则，根据isReadyonly返回响应数据
    return isObject(res)
      ? isReadonly
        ? // need to lazy access readonly and reactive here to avoid
          // circular dependency
          readonly(res)
        : reactive(res)
      : res
  }

大致看下来会发现，get的方法的每个表达式其实都比较简单，不过却好像都有点儿懵。

问题 1: 为什么要通过Reflect, 而不是直接target[key]?

确实，target[key]好像就能实现效果了，为什么要用Reflect，还要传个receiver呢？原因在于原始数据的get并没有大家想的这么简单，比如这种情况：

const targetObj = {
  get a() {
    return this
  }
}
const proxyObj = reactive(targetObj)

这个时候，proxyObj.a在你想象中应该是proxyObj还是targetObj呢？我觉得合理来说应该是proxyObj。但a又不是一个方法，没法直接call/apply。要实现也可以，比较绕，约等于实现了Reflect的 polyfill。所以感谢 ES6，利用Reflect，可方便的把现有操作行为原模原样地反射到目标对象上，又保证真实的作用域（通过第三个参数receiver）。这个receiver即是生成的代理对象，在上述例子中即是proxyObj。

问题 2: 为什么内置方法不需要收集依赖?

如果一个监听函数是这样的：

const origin = {
  a() {}
}
const observed = reactive(origin)
effect(() => {
  console.log(observed.a.toString())
})

很明显，当origin.a 变化时，observed.a.toString()也是应该会变的，那为什么不用监听了呢？很简单，因为已经走到了observed.a.toString()已经走了一次get的 trap，没必要重复收集依赖。故而类似的内置方法，直接 return。

问题 3: 为什么属性值为对象时，需要再用reactive|readonly执行？

注释中写了：

need to lazy access readonly and reactive here to avoid circular dependency

翻译成普通话是，需要延迟地使用reactive|readonly来避免循环依赖。这话需要品，细细品，品了一会儿以后终于品懂了。

因为由于Proxy这玩意儿吧，它的trap其实只能劫持对象的第一层访问与更新。如果是嵌套对象，其实是劫持不了的。那我们就有了两种方法：

方法一：当通过reactive|readonly转化原始对象时，一层一层的递归解套，如果是对象，就再用reactive执行、然后走ProxyHandle。以后访问这些嵌套属性时，自然也会走到 trap。但这样有个大问题，如果对象是循环引用的呢？那必然是要有个逻辑判断，如果发现属性值是自身则不递归了。那如果是半路循环引用的呢？比如这样：

const a = {
  b: {
    c: a
  }
}

const A = {
  B: {
    C: a
  }
}

想想都头大吧。

方法二：也即是源码中的方法，转化原始对象时，不递归。后续走到get的 trap 时，如果发现属性值是个对象，再继续转化、劫持。也就是注释中所讲到的lazy。利用这个办法，自然就可以避免循环引用了。另外还有个显而易见的好处是，可以优化性能。

除了这个三个问题外，还有一个小细节：

if (isRef(res)) {
  return res.value
}

如果是Ref类型的数据，则直接返回 value 值。因为在ref函数中，已经做了相关的依赖跟踪逻辑。另外，如果看过单测篇跟 ref 篇，我们知道就是此处代码实现了这样的能力：向reacitive函数传递一个嵌套的Ref类型数据，可返回一个递归解套了Ref类型的响应式数据。reactive函数的返回类型为UnwrapNestedRefs归功于此。

不过切记：向reactive传一个纯粹的Ref类型数据，是不会解套的，它只解套被嵌套着的Ref数据。示例如下：

reactive(ref(4)) // = ref(4);
reactive({ a: ref(4) }) // = { a: 4 }

那到此为止，除了track是外部引入的用来收集依赖的方法外（后面再看），get已经摸透了。

下面看set。

set

function set(
  target: any,
  key: string | symbol,
  value: any,
  receiver: any
): boolean {
  // 如果value是响应式数据，则返回其映射的源数据
  value = toRaw(value)
  // 获取旧值
  const oldValue = target[key]
  // 如果旧值是Ref数据，但新值不是，那更新旧的值的value属性值，返回更新成功
  if (isRef(oldValue) && !isRef(value)) {
    oldValue.value = value
    return true
  }
  // 代理对象中，是不是真的有这个key，没有说明操作是新增
  const hadKey = hasOwn(target, key)
  // 将本次设置行为，反射到原始对象上
  const result = Reflect.set(target, key, value, receiver)
  // don't trigger if target is something up in the prototype chain of original
  // 如果是原始数据原型链上的数据操作，不做任何触发监听函数的行为。
  if (target === toRaw(receiver)) {
    // istanbul 是个单测覆盖率工具
    /* istanbul ignore else */
    if (__DEV__) {
      // 开发环境下，会传给trigger一个扩展数据，包含了新旧值。明显的是便于开发环境下做一些调试。
      const extraInfo = { oldValue, newValue: value }
      // 如果不存在key时，说明是新增属性，操作类型为ADD
      // 存在key，则说明为更新操作，当新值与旧值不相等时，才是真正的更新，进而触发trigger
      if (!hadKey) {
        trigger(target, OperationTypes.ADD, key, extraInfo)
      } else if (value !== oldValue) {
        trigger(target, OperationTypes.SET, key, extraInfo)
      }
    } else {
      // 同上述逻辑，只是少了extraInfo
      if (!hadKey) {
        trigger(target, OperationTypes.ADD, key)
      } else if (value !== oldValue) {
        trigger(target, OperationTypes.SET, key)
      }
    }
  }
  return result
}

set跟get一样，每句表达式都很清晰，但我们依旧存在疑问。

问题 1：isRef(oldValue) && !isRef(value)这段是什么逻辑？

// 如果旧值是 Ref 数据，但新值不是，那更新旧的值的 value 属性值，返回更新成功
if (isRef(oldValue) && !isRef(value)) {
  oldValue.value = value
  return true
}

什么情况下 oldValue 会是个Ref数据呢？其实看get部分的时候，我们就知道啦，reactive有解套嵌套 ref 数据的能力，如：

const a = {
  b: ref(1)
}
const observed = reactive(a) // { b: 1 }

此时，observed.b输出的是 1，当做赋值操作 observed.b = 2时。oldValue由于是a.b，是一个Ref类型数据，而新的值并不是，进而直接修改a.b的 value 即可。那为什么直接返回，不需要往下触发 trigger 了呢？是因为在ref函数中，已经有劫持 set 的逻辑了(不贴代码了)。

问题 2：什么时候会target !== toRaw(receiver)？

在之前的认知中，receiver有点儿像是this一样的存在，指代着被 Proxy 执行后的代理对象。那代理对象用toRaw转化，也就是转为原始对象，自然跟target是全等的。这里就涉及了一个偏门的知识点，详细介绍可以看MDN。其中有说到：

Receiver：最初被调用的对象。通常是 proxy 本身，但 handler 的 set 方法也有可能在原型链上或以其他方式被间接地调用（因此不一定是 proxy 本身）

这就是代码中的注释背后的意义：

don't trigger if target is something up in the prototype chain of original.

举个实例来说就像这样：

const child = new Proxy(
  {},
  {
    get(target, key, receiver) {
      return Reflect.get(target, key, receiver)
    },
    set(target, key, value, receiver) {
      Reflect.set(target, key, value, receiver)
      console.log('child', receiver)
      return true
    }
  }
)

const parent = new Proxy(
  { a: 10 },
  {
    get(target, key, receiver) {
      return Reflect.get(target, key, receiver)
    },
    set(target, key, value, receiver) {
      Reflect.set(target, key, value, receiver)
      console.log('parent', receiver)
      return true
    }
  }
)

Object.setPrototypeOf(child, parent)

child.a = 4

// 打印结果
// parent Proxy {child: true, a: 4}
// Proxy {child: true, a: 4}

在这种情况下，这个父对象parent的set竟然也会被触发一次，只不过传递的receiver都是child，进而被更改数据的也一直是child。在这种情况下，parent其实并没有变更，按道理来说，它确实不应该触发它的监听函数。

问题 3: 数组可能通过方法更新数据，这过程的监听逻辑是怎么样的？

对于一个对象来说，我们可以直接赋值属性值，但对于数组呢？假使const arr = []，那它既可以arr[0] = 'value'，也可以arr.push('value')，但并没有一个trap是劫持 push 的。但是当你真正去调试时，发现push还会触发两次set。

const proxy = new Proxy([], {
  set(target, key, value, receiver) {
    console.log(key, value, target[key])
    return Reflect.set(target, key, value, receiver)
  }
})
proxy.push(1)
// 0 1 undefined
// length 1 1

其实push的内部逻辑就是先给下标赋值，然后设置length，触发了两次set。不过还有个现象是，虽然push带来的length操作会触发两次set，但走到 length 逻辑时，获取老的 length 也已经是新的值了，所以由于value === oldValue，实际只会走到一次trigger。但是！如果是shift或unshift，这样的逻辑又不成立了，而且如果数组长度是 N，shift|unshift就会带来 N 次的trigger。这里其实涉及了Array的底层实现与规范，我也无法简单的阐述明白，建议可以自己去看ECMA-262中关于Array的相关标准。

不过这里确实留下一个小坑，shift|unshift以及splice，会带来多次的 effect 触发。在reacivity系统中，目前还没看到相关的优化。当然，真实在使用 vue@3 的过程中，runtime-core还是会针对渲染做批量更新的。

那到这，set本身的逻辑我们也摸透了，除了一个外部引入的trigger。不过我们知道它是当数据变更时触发监听函数的就好，后面再看。

接下来就比较简单了。

其他 traps

// 劫持属性删除
function deleteProperty(target: any, key: string | symbol): boolean {
  const hadKey = hasOwn(target, key)
  const oldValue = target[key]
  const result = Reflect.deleteProperty(target, key)
  if (result && hadKey) {
    /* istanbul ignore else */
    if (__DEV__) {
      trigger(target, OperationTypes.DELETE, key, { oldValue })
    } else {
      trigger(target, OperationTypes.DELETE, key)
    }
  }
  return result
}
// 劫持 in 操作符
function has(target: any, key: string | symbol): boolean {
  const result = Reflect.has(target, key)
  track(target, OperationTypes.HAS, key)
  return result
}
// 劫持 Object.keys
function ownKeys(target: any): (string | number | symbol)[] {
  track(target, OperationTypes.ITERATE)
  return Reflect.ownKeys(target)
}

这几个trap基本没啥难点了，一眼能看明白。

最后看下readonly的特殊逻辑：

readonly

export const readonlyHandlers: ProxyHandler<any> = {
  // 创建get的trap
  get: createGetter(true),
  // set的trap
  set(target: any, key: string | symbol, value: any, receiver: any): boolean {
    if (LOCKED) {
      // 开发环境操作只读数据报警告。
      if (__DEV__) {
        console.warn(
          `Set operation on key "${String(key)}" failed: target is readonly.`,
          target
        )
      }
      return true
    } else {
      // 如果不可变开关已关闭，则允许设置数据变更
      return set(target, key, value, receiver)
    }
  },
  // delete的trap，逻辑跟set差不多
  deleteProperty(target: any, key: string | symbol): boolean {
    if (LOCKED) {
      if (__DEV__) {
        console.warn(
          `Delete operation on key "${String(
            key
          )}" failed: target is readonly.`,
          target
        )
      }
      return true
    } else {
      return deleteProperty(target, key)
    }
  },
  has,
  ownKeys
}

readonly也很简单啦，createGetter的逻辑之前已经看过了。不过有些没绕过来的同学可能会想，get的 trap 又不改变数据，为什么要跟reactive的做区分，传个isReadonly呢？那是因为上文中讲到的，通过get做依赖收集时，对于嵌套的对象数据，是延迟劫持的，所以只能透传了isReadonly，让后续劫持的子对象知道自身是否应该只读。

has跟ownKeys由于不改变数据，也不用递归收集依赖，自然就不用跟可变数据的逻辑做区分了。

看完以后，依赖收集跟触发监听函数的时机，我们就能基本了解了。

小总结

关于 baseHandles 我们做个小总结：

对于原始对象数据，会通过 Proxy 劫持，返回新的响应式数据(代理数据)。
对于代理数据的任何读写操作，都会通过Refelct反射到原始对象上。
在这个过程中，对于读操作，会执行收集依赖的逻辑。对于写操作，会触发监听函数的逻辑。

总结下来，其实还是比较简单的。但是我们还落了对于集合数据的 handlers 没看，这块才是真正的硬骨头。

collectionHandlers

打开这个文件，发现这个文件比reactive跟baseHandlers可长了不少。没想到对于这种平常不怎么用的数据类型的处理，才是最麻烦的。

为什么单独处理

看源码前，其实会有个疑问，为什么Set|Map|WeakMap|WeakSet这几个数据需要特殊处理呢？跟其他数据有什么区别吗？我们点开文件，看看这个handlers，发现竟然是这样：

export const mutableCollectionHandlers: ProxyHandler<any> = {
  get: createInstrumentationGetter(mutableInstrumentations)
}
export const readonlyCollectionHandlers: ProxyHandler<any> = {
  get: createInstrumentationGetter(readonlyInstrumentations)
}

只有get，没有set、has这些。这就懵了，说好的劫持set跟get呢？为什么不劫持set了？原因是没法这么做，我们可以简单的做个尝试：

const set = new Set([1, 2, 3])
const proxy = new Proxy(set, {
  get(target, key, receiver) {
    console.log(target, key, receiver)
    return Reflect.get(target, key, receiver)
  },
  set(target, key, value, receiver) {
    console.log(target, key, value, receiver)
    return Reflect.set(target, key, value, receiver)
  }
})
proxy.add(4)

这段代码，一跑就会出一个错误：

Uncaught TypeError: Method Set.prototype.add called on incompatible receiver [object Object]

发现只要劫持set，或者直接引入了Reflect，反射行为到target上，就会报错。为什么会这样呢？这其实也是跟Map|Set这些的内部实现有关，他们内部存储的数据必须通过this来访问，被成为所谓的“internal slots”，而通过代理对象去操作时，this其实是 proxy，并不是 set，于是无法访问其内部数据，而数组呢，由于一些历史原因，又是可以的。详细解释可以见这篇关于 Proxy 的限制的介绍。这篇文章中也提到了解决办法：

let map = new Map()
let proxy = new Proxy(map, {
  get(target, prop, receiver) {
    let value = Reflect.get(...arguments)
    return typeof value == 'function' ? value.bind(target) : value
  }
})
proxy.set('test', 1)

大致原理就是，当获取的是一个函数的时候，将this绑定为原始对象，也即是想要劫持的map|set。这样就避免了this的指向问题。

那我们就有点儿明白，为什么collection数据需要特殊处理，只劫持一个get了。具体怎么做呢？我们来看代码。

按惯例先看引用与工具方法：

import { toRaw, reactive, readonly } from './reactive'
import { track, trigger } from './effect'
import { OperationTypes } from './operations'
import { LOCKED } from './lock'
import {
  isObject,
  capitalize, // 首字母转成大写
  hasOwn
} from '@vue/shared'

// 将数据转为reactive数据，如果不是对象，则直接返回自身
const toReactive = (value: any) => (isObject(value) ? reactive(value) : value)
const toReadonly = (value: any) => (isObject(value) ? readonly(value) : value)

这些引用，我们应该基本不用看注释都能明白了，除了一个工具方法capitalize需要点开看看外，基本一眼明白。然后我们需要调整下阅读顺序，先大致看看到底如何通过一个get的trap，劫持写操作。

插桩

// proxy handlers
export const mutableCollectionHandlers: ProxyHandler<any> = {
  // 创建一个插桩getter
  get: createInstrumentationGetter(mutableInstrumentations)
}

首先，我们要读懂它的函数名，createInstrumentationGetter。唔，像我一样英文比较差的同学可能是不太懂Instrumentation是什么意思的。这里是表达“插桩”的意思。关于“插桩”我不多介绍啦，常见的单测覆盖率往往就是通过插桩实现的。

在本代码中，插桩即指向某个方法被注入一段有其他作用的代码，目的就是为了劫持这些方法，增加相应逻辑，那我们看看此处是如何“插桩”(劫持)的。

// 可变数据插桩对象，以及一系列相应的插桩方法
const mutableInstrumentations: any = {
  get(key: any) {
    return get(this, key, toReactive)
  },
  get size() {
    return size(this)
  },
  has,
  add,
  set,
  delete: deleteEntry,
  clear,
  forEach: createForEach(false)
}
// 迭代器相关的方法
const iteratorMethods = ['keys', 'values', 'entries', Symbol.iterator]
iteratorMethods.forEach(method => {
  mutableInstrumentations[method] = createIterableMethod(method, false)
  readonlyInstrumentations[method] = createIterableMethod(method, true)
})
// 创建getter的函数
function createInstrumentationGetter(instrumentations: any) {
  // 返回一个被插桩后的get
  return function getInstrumented(
    target: any,
    key: string | symbol,
    receiver: any
  ) {
    // 如果有插桩对象中有此key，且目标对象也有此key，
    // 那就用这个插桩对象做反射get的对象，否则用原始对象
    target =
      hasOwn(instrumentations, key) && key in target ? instrumentations : target
    return Reflect.get(target, key, receiver)
  }
}

从上文中知道，由于Proxy跟collection数据的原生特性，无法劫持set或者直接反射。所以在这里，创建了一个新的对象，它具有set跟map一样的方法名。这些方法名对应的方法就是插桩后，注入了依赖收集跟响应触发的方法。然后通过Reflect反射到这个插桩对象上，获取的是插桩后的数据，调用的是插桩后的方法。

而对于一些自定义的属性或方法，Reflect反射的就不是插桩过后的，而是原数据，对于这些情况，也不会做响应式的逻辑，比如单测中的：

it('should not observe custom property mutations', () => {
  let dummy
  const map: any = reactive(new Map())
  effect(() => (dummy = map.customProp))

  expect(dummy).toBe(undefined)
  map.customProp = 'Hello World'
  expect(dummy).toBe(undefined)
})

插桩读操作

接下来看这个插装器mutableInstrumentations，从上往下，我们先看get。

const mutableInstrumentations: any = {
  get(key: any) {
    // this 即是调用get的对象，现实情况就是Proxy代理对象
    // toReactive是一个将数据转为响应式数据的方法
    return get(this, key, toReactive)
  }
  // ...省略其他
}
function get(target: any, key: any, wrap: (t: any) => any): any {
  // 获取原始数据
  target = toRaw(target)
  // 由于Map可以用对象做key，所以key也有可能是个响应式数据，先转为原始数据
  key = toRaw(key)
  // 获取原始数据的原型对象
  const proto: any = Reflect.getPrototypeOf(target)
  // 收集依赖
  track(target, OperationTypes.GET, key)
  // 使用原型方法，通过原始数据去获得该key的值。
  const res = proto.get.call(target, key)
  // wrap 即传入的toReceive方法，将获取的value值转为响应式数据
  return wrap(res)
}

注意：在get方法中，第一个入参target不能跟Proxy构造函数的第一个入参混淆。Proxy函数的第一个入参target指的原始数据。而在get方法中，这个target其实是被代理后的数据。也即是Reflect.get(target, key, receiver)中的receiver。

然后我们就比较清晰了，本质就是通过原始数据的原型方法+call this，避免了上述的问题，返回真正的数据。

const mutableInstrumentations: any = {
  // ...
  get size() {
    return size(this)
  },
  has
  // ...
}
function size(target: any) {
  // 获取原始数据
  target = toRaw(target)
  const proto = Reflect.getPrototypeOf(target)
  track(target, OperationTypes.ITERATE)
  return Reflect.get(proto, 'size', target)
}

function has(this: any, key: any): boolean {
  // 获取原始数据
  const target = toRaw(this)
  key = toRaw(key)
  const proto: any = Reflect.getPrototypeOf(target)
  track(target, OperationTypes.HAS, key)
  return proto.has.call(target, key)
}

size跟has，都是“查”的逻辑。只是size是一个属性，不是方法，所以需要以get size()的方式去劫持。而has是个方法，不需要专门绑定 this，两者内部逻辑也简单，跟get基本一致。不过这里有个关于 TypeScript 的小细节。has函数第一个入参是this，这个在 ts 里是假的参数，真正调用这个函数的时候，是不需要传递的，所以依旧是这样使用someMap.has(key)就好。

那除了这两个查方法，还有迭代器相关的“查”方法。

插桩迭代器

关于迭代器，如果没什么了解，建议先阅读相关文档，比如MDN。

// 迭代器相关的方法
const iteratorMethods = ['keys', 'values', 'entries', Symbol.iterator]
iteratorMethods.forEach(method => {
  mutableInstrumentations[method] = createIterableMethod(method, false)
})
function createIterableMethod(method: string | symbol, isReadonly: boolean) {
  return function(this: any, ...args: any[]) {
    // 获取原始数据
    const target = toRaw(this)
    // 获取原型
    const proto: any = Reflect.getPrototypeOf(target)
    // 如果是entries方法，或者是map的迭代方法的话，isPair为true
    // 这种情况下，迭代器方法的返回的是一个[key, value]的结构
    const isPair =
      method === 'entries' ||
      (method === Symbol.iterator && target instanceof Map)
    // 调用原型链上的相应迭代器方法
    const innerIterator = proto[method].apply(target, args)
    // 获取相应的转成响应数据的方法
    const wrap = isReadonly ? toReadonly : toReactive
    // 收集依赖
    track(target, OperationTypes.ITERATE)
    // return a wrapped iterator which returns observed versions of the
    // values emitted from the real iterator
    // 给返回的innerIterator插桩，将其value值转为响应式数据
    return {
      // iterator protocol
      next() {
        const { value, done } = innerIterator.next()
        return done
          ? // 为done的时候，value是最后一个值的next，是undefined，没必要做响应式转换了
            { value, done }
          : {
              value: isPair ? [wrap(value[0]), wrap(value[1])] : wrap(value),
              done
            }
      },
      // iterable protocol
      [Symbol.iterator]() {
        return this
      }
    }
  }
}

这段逻辑其实还好，核心就是劫持迭代器方法，将每次next返回的 value 用reactive转化。唯一会让人不清楚的，其实是对于Iterator以及Map|Set的不熟悉。如果确实不熟悉，建议还是先看下它们的相关文档。

迭代器相关的还有一个forEach方法。

function createForEach(isReadonly: boolean) {
  // 这个this，我们已经知道了是假参数，也就是forEach的调用者
  return function forEach(this: any, callback: Function, thisArg?: any) {
    const observed = this
    const target = toRaw(observed)
    const proto: any = Reflect.getPrototypeOf(target)
    const wrap = isReadonly ? toReadonly : toReactive
    track(target, OperationTypes.ITERATE)
    // important: create sure the callback is
    // 1. invoked with the reactive map as `this` and 3rd arg
    // 2. the value received should be a corresponding reactive/readonly.
    // 将传递进来的callback方法插桩，让传入callback的数据，转为响应式数据
    function wrappedCallback(value: any, key: any) {
      // forEach使用的数据，转为响应式数据
      return callback.call(observed, wrap(value), wrap(key), observed)
    }
    return proto.forEach.call(target, wrappedCallback, thisArg)
  }
}

forEach的逻辑并不复杂，跟上面迭代器部分差不多，也是劫持了方法，将原本的传参数据转为响应式数据后返回。

插桩写操作

然后看写操作。

function add(this: any, value: any) {
  // 获取原始数据
  value = toRaw(value)
  const target = toRaw(this)
  // 获取原型
  const proto: any = Reflect.getPrototypeOf(this)
  // 通过原型方法，判断是否有这个key
  const hadKey = proto.has.call(target, value)
  // 通过原型方法，增加这个key
  const result = proto.add.call(target, value)
  // 原本没有key的话，说明真的是新增，则触发监听响应逻辑
  if (!hadKey) {
    /* istanbul ignore else */
    if (__DEV__) {
      trigger(target, OperationTypes.ADD, value, { value })
    } else {
      trigger(target, OperationTypes.ADD, value)
    }
  }
  return result
}

我们发现写操作倒简单多了，其实跟baseHandlers的逻辑是差不多的，只不过对于那些base数据，可以通过Reflect方便的反射行为，而在此处，需要手动获取原型链并绑定this而已。查看set跟deleteEntry的代码，逻辑也差不多，就不多阐述了。

关于readonly相关的也很简单了，我也不贴了代码了，纯粹增加文章字数。它就是将add|set|delete|clear这几个写方法再包一层，开发环境下抛个 warning。

到这里，终于看完了collcetionsHandlers的全部逻辑了。

小总结

再总结一下它是如何劫持 collcetion 数据的。

由于Set|Map等集合数据的底层设计问题，Proxy无法直接劫持set或直接反射行为。
劫持原始集合数据的get，对于它的原始方法或属性，Reflect反射到插桩器上，否则反射原始对象。
插装器上的方法，会先通过toRaw，获取代理数据的原始数据，再获取原始数据的原型方法，然后绑定this为原始数据，调取相应方法。
对于getter|has这类查询方法，插入收集依赖的逻辑，并将返回值转为响应式数据（has 返回 boolean 值故不需要转换）。
对于迭代器相关的查询方法，插入收集依赖逻辑，并将迭代过程的数据转为响应式数据。
对于写操作相关方法，插入触发监听的逻辑。

其实原理还是好理解的，只是写起来比较麻烦。

总结

那到此为止，终于把reactive的逻辑完全理完了。阅读本部分的代码有点儿不容易，因为涉及的底层知识比较多，不然会处处懵逼，不过这也是一种学习，探索的过程也是挺有意思的。

在这过程中，我们发现，数组的劫持目前还是存在一点点不足的，直接通过反射，会在一些情况下重复触发监听函数。感觉通过类似collection数据的处理方式可以解决。但是这又增加了程序复杂度，而且也不知道会不会有一些其他的坑。

另外，我们发现阅读reactivity相关的代码时，ts 涉及的没我们想象中的多，内部很多情况下是 any 的，但这是要辩证的看的。首先如小右所说，“这些数据是用户数据，本身就是any的，勉强要声明，没有什么意义”。而且那一路下来都是非常多的泛型加推导，成本非常高。反正我自己尝试了下，是无能为力的。另外当前代码还是非正式的阶段，如果维护起来过于麻烦。那对于我这种 ts 半吊子的人，如果真的想再贡献一点代码，也是举步维艰。

这篇文章有点儿繁杂，如果是慢慢看下来的，非常感谢你的阅读~~

下篇是最后的effect相关的源码解析，终于能解开最开始targetMap的谜团，看到track跟trigger的内部实现，凑上最后一块拼图了。