Intro
Vue3有两个函数可以用于创建响应式数据。不严谨但简单地说，响应式数据的意思是：该数据的变化，最终会导致页面中的实际数据变化。这两种方式分别为ref函数和reactive函数，Vue官方在文档中说明了ref在包装对象时，底层会用到reactive，并且推荐多数情况下优先使用ref一把梭。
ref的使用：
const data = ref('some data string');
// 在script中，其value字段的值就是响应式对象所持有的数据
console.log(data.value) // output: some data string
// 在template中相当于Vue手动添加了.value,不用手动写
<div> {{data}}</div>
reactive的使用：
const data = reactive({a:'hello world'});
// 在script中，响应式对象本身就是数据，不用.value
console.log(data.a) // output: hello world
// 在template中自然也不用.value
<div> {{data}}</div>
ref跟reactive的主要区别：
ref可以包装原始类型的对象，如string，number，bool值，但reactive只能包装对象
ref的value字段才是要用的值，而reactive直接用就可以
ref和reactive的大致实现原理
事实上，ref的底层实现用到了reactive的实现，当传入一个对象给ref时，ref会调用reactive返回一个响应式对象，并赋值给自己的value属性，当自己的value属性被读取或者赋值时会触发拦截。当传入一个obj给reactive函数创建响应式对象时，vue使用的是代理模式，这样就可以拦截到对该对象的任意字段的新增，删除，修改和读取了。而如果整个代理对象被替换，那自然就失效了，但是如果是ref创建的，你替换掉reactive对象，正好触发ref的value属性的赋值，被拦截下来了，所以响应式不会丢失。
很容易看出，ref的value属性的读取和赋值被拦截，这正好跟vue2的响应式原理差不多，本质上是用Object.defineProperty来拦截对于对象的读取和赋值。而vue2中正因为采用了这种方式来实现响应式，所以才导致如果对象临时新增或删除字段，响应式感知不到对象的变化，因此页面不会更新，所以才有vue2中的this.$set方法来打补丁。而采用proxy的方式，可以拦截读取，赋值，新增和删除字段，这些都可以拦截，更方便。而对于替换掉整个对象这种操作，又恰好等效于ref响应式对象的value字段被赋新值了，所以ref才这么完美，无论怎么玩，都不会丢响应式。
总之，响应式说到底，就是用各种方式拦截数据的变化。具体而言拦截分两种，当第一次获取这个数据的字段时，拦截下来，收集依赖，在我的小本本上记录下某某函数用到了某某对象的某某字段，所以等这个某某对象的某某字段的值变化时，我要通知所有依赖它的这些函数，计算新值，以便触发后续的一些操作和页面的更新。
测试题-什么时候会拦截
let state = ref(1);
state; // 不会拦截，因为我只是读取了state这个响应式对象，并没有读取这个响应式对象的value属性，那说明我并不依赖于这个响应式数据，这个响应式对象里面的值变化了，关我什么事？
console.log(state); // 依然不会拦截，理由同上，因为没有读取value属性
console.log(state.value); // 会拦截，因为访问了 value 属性。假设这个console.log函数是在computed,watchEffect等函数中的话，那说明该函数依赖了这个数据，等state.value的值变化了，那我肯定要重新运行的。
console.log(state.a); // 不会拦截，没有读取value属性啊，我的value属性才是需要用到的数据，你读我的a不关我事。
state.a = 3; // 不会拦截，我的value属性才是需要用到的属性
state.value = 3; // 会拦截，而且是赋值，那我需要做的可能就是要触发用到这个响应式数据的地方（例如页面中）的更新了
delete state.value; // 不会拦截，因为ref的value使用的是Object.defineProperty的方式，删除字段，我并不知道。而且似乎删除value字段本身就是不被允许的，编译就通不过
state = 3; // 不会拦截，没有对value做什么，并且好家伙，直接把state作为一个ref对象变成了一个普通number，奇才
接下来的foo函数假设是watchEffect这样的函数，运行一次，会拦截么？
var a = ref({ b: 1 });
const k = a.value;
const n = k.b;
functionfoo() {
a; // 不会，因为a是一个ref对象，没有读或者写其value属性
a.value;// 会，因为读取了value字段，所以如果之后a.value更新，我是要通知foo重新运行的
k.b;// 会，如果不考虑死板的规则，单纯从业务开发的角度上来讲，这里也“应该”是要收集依赖的，因为b字段作为响应式数据的一个字段，显然它变化了，我肯定要更新依赖它的那些函数或界面的。如果从纯粹的拦截规则来看，k是一个reactive代理对象，对一个reactive代理对象的某个字段读取，那当然是会拦截的。
n;
}
坑：
关于最后一个n,是否会导致收集依赖。答案是不会，这个一开始可能会被误导，觉得会，是因为有一个const n = k.b，所以下意识会觉得既然k.b被拦截了，那自然n也会被拦截。但这里n只是一个单纯的值为1的number类型的变量，并不是响应式变量，n只是恰好和k.b的值相等罢了。从业务开发的角度来说也很合理，我只是把响应式对象的b字段的值保存下来，存到n里面了，我之后如果更改了n的值，那关依赖a.value.b什么事？又不是它的值变化了。
那这个时候有人会说：行，那如果b字段不是1这个数字，而是一个对象呢？
var a = ref({ b: {c:1} });
const k = a.value;
const n = k.b;
functionfoo() {n;}
这样总该收集依赖了吧？reactive会对对象的每个非原始类型的字段递归处理，使其也变为一个reactive对象，n是一个reactive proxy对象，那总该收集依赖了吧？答案仍然是不会。
依然从两个角度来回答：
从纯规则的角度出发：n确实是一个reactive proxy对象的引用，但是这个过程中并没有访问某个proxy对象的某个字段，访问的是proxy对象本身。只有像k.b这种，k是一个proxy对象，b是proxy对象的字段，这种才会被拦截到。
从业务的角度来说，这也是合理的，我的watchEffect函数中有一个地方用到了n，而不是k.b，之后n的值变了，关我什么事？我关注的是响应式数据的内容有没有变化。虽然目前n确实是一个proxy对象，和k.b都指向同一个proxy对象的内存地址，但我之后更改n为另一对象或者干脆就是一个原始类型的值了，那并没有对响应式对象本身的值做干扰啊？k.b指向的那个对象根本没有随着n的值而发生改变。我让n的值变为了3，但是并不影响k.b仍然是一个reactive proxy对象，其有一个字段名为c，其值为1。只有我显示地让k.b = {xxx:"42"}的时候，才实际更改了响应式对象中的数据。这有点像函数传参的时候：
// p1是一个对象的引用
functionfunc(p1){
p1 = {a:1,b:2};
}
let p1 = {name:"xiaoming"}
func(p1)
console.log(p1) // 仍然输出{name:"xiaoming"}，因为只是把形参的p1的指向更改了，并没有更改实参p1的实际指向。
// p1是一个对象的引用
functionfunc(p1){
p1.a = 1
}
let p1 = {name:"xiaoming"}
func(p1)
console.log(p1) // 输出{name:"xiaoming",a:1}，因为形参的p1与实参的p1指向同一个对象，所以形参p1在里面新增加的a字段会实际生效。
所以，以下的例子也很好理解：
var a = ref({ b: {c:1} });
const k = a.value;
const n = k.b;
functionfoo() {n.c;} // 这样确实是会造成依赖收集的，因为n是一个proxy对象，读取了一个proxy对象的某个字段。当n.c确实被赋予新值时，说明响应式数据本身变了，那确实得更新
