目录
示例
源码
其实，在不看源码之前，就已经能想到其大概实现逻辑了：每一个effect在执行过程中如果遇到设置了响应式的值那么就会执行依赖收集，那么此时如果打一个标记，并根据此标记将存在依赖的effect放到某个队列中。当依赖改变后从队列中挑选判断并执行即可
接下来就来验证下是不是这样
将代码定位到effect函数
可以看到这里获取了ReactiveEffect实例，紧接着又调用了.run方法
在分析响应式的时候，创建的ReactiveEffect实例接收的是componentUpdateFn，这将在初始化以及派发更新阶段被执行进行组件的render和patch
（调用.run执行）
故，只需要着重看，它在初始化以及更新阶段是如何被触发的即可，显然初始化阶段已经执行了.run
那么来看更新阶段，根据使用方式，是否重新触发取决于是否在内部使用了响应式数据
对于第一个effect而言，只有一个输出信息，执行完也就结束了
对于第二个，则会触发reactive的依赖收集，那么此时全局的activeEffect将会被替换为当前实例并被收集进dep中
此时的dep中存在两个依赖
如此，当执行changeMsg函数时，将触发trigger走triggerEffects流程对收集在dep中的依赖做派发更新通知。对于effect的依赖实例而言，是没有scheduler标识的，故走的是第二个逻辑
（这跟vue2的做法差别不大，vue2中也分render watcher、computed watcher等，都是使用某个属性key做区分）
总结
实例化观察者ReactiveEffect类，对其标记不同的属性（component dep有scheduler，effect dep没有），利用响应式遍历每一个观察者做对应的更新操作.。对于effect而言，就是重新再跑一遍
