createPatchFunction 即是 patch 方法调用的实际函数，执行时会将传入的真实DOM节点转换成虚拟节点，然后执行 createElm
createElm 会根据新的虚拟节点生成真实DOM节点，内部同样调用 createElement 方法来创建节点。
insert 方法将生成的真实DOM插入到DOM树中
removeVnodes 最后将之前转换的真实DOM节点从DOM树中移除
以上就是一般初始化Vue实例组件时渲染的路径，在这个过程中，初始 VNode 虽然不存在，但是由于挂在的真实 DOM 节点一定存在，所以代码会按照这样的流程来执行。
组件数据更新刷新DOM
一般情况下，数据变成会通知 Watcher 实例调用 update 方法，这个方法在一般情况下会把待渲染的数据观察对象加入到事件任务队列中，避免开销过高在一次处理中集中执行。所以在 mount 路径已经完成了之后，生命周期运行期间都是走的 update 路径，在每一次的事件处理中 nextTick 会调用 flushSchedulerQueue 来开始一轮页面刷新：
flushSchedulerQueue => watcher.run => watcher.getAndInvoke => watcher.get => updateComponent => _render => _update => createPatchFunction(patch) => patchVnode => updateChildren在这个流程中各个方法的大致处理如下：
flushSchedulerQueue 调用每一个变更了的数据的监视器的 run 方法
run 执行调用实例的 getAndInvoke 方法，目的是获取新数据并调用监视器的回调函数
getAndInvoke 执行的第一步是要获取变更后的新数据，在这时会调用取值器函数
get 执行的取值器函数getter被设定为 updateComponent ，所以会执行继续执行它
updateComponent => createPatchFunction 之间的流程与另一条路径相同，只是其中基于新旧虚拟节点的判断不一样，如果存在旧虚拟节点就执行 patchVnode 操作。
patchVnode 方法是实际更新节点的实现，在这个函数的执行中，会得到最终的真实DOM
生命周期中的渲染主要是以上两条路径，调用的入口不同，但中间有一部分逻辑是公用的，再根据判断来选择分离的路程来更新 VNode 和刷新节点。在这个过程可以看出 VNode 的重要作用。
虽然路径大致可以这样总结，但其中的实现比较复杂。不仅在流程判断上非常有跳跃性，实现更新真实节点树的操作也都是复杂递归的调用。
总的来说虚拟节点的实现是非常平易近人，但是在节点渲染的过程中却被运用的十分复杂，段位不够高看了很多遍测试了很多遍才弄清楚整个执行流，这之外还有关于服务器端渲染和持久活跃组件的部分暂时都忽略了。不过关于节点渲染这一部分的实现逻辑非常值得去好好研究。
