以下题目及答案来自于童欧巴-「面试题」20+Vue面试题整理(持续更新)加上一些我自己的理解。
MVVM是Model-View-ViewModel缩写，也就是把MVC中的Controller演变成ViewModel。Model层代表数据模型，View代表UI组件，ViewModel是View和Model层的桥梁，数据会绑定到viewModel层并自动将数据渲染到页面中，视图变化的时候会通知viewModel层更新数据。
Vue在初始化数据时，会使用Object.defineProperty重新定义data中的所有属性，当页面使用对应属性时，首先会进行依赖收集(收集当前组件的watcher)如果属性发生变化会通知相关依赖进行更新操作(发布订阅)。
Vue3.x改用Proxy替代Object.defineProperty。Object.defineProperty 虽然已经能够实现双向绑定了，但是他还是有缺陷的。
- 只能对属性进行数据劫持，所以需要深度遍历整个对象
- 对于数组不能监听到数据的变化
反观 Proxy 就没以上的问题，原生支持监听数组变化，并且可以直接对整个对象进行拦截，并且有13种劫持方式。不过缺点也很明显，因为它是ES6提供的新特性，存在兼容性问题，这也就是为什么Vue3.x只能支持IE11以上的原因。
判断当前Reflect.get的返回值是否为Object，如果是则再通过reactive方法做代理， 这样就实现了深度观测。
我们可以判断key是否为当前被代理对象target自身属性，也可以判断旧值与新值是否相等，只有满足以上两个条件之一时，才有可能执行trigger。
使用了函数劫持的方式，重写了数组的方法，Vue将data中的数组进行了原型链重写，指向了自己定义的数组原型方法。这样当调用数组api时，可以通知依赖更新。如果数组中包含着引用类型，会对数组中的引用类型再次递归遍历进行监控。这样就实现了监测数组变化。
nextTick批量异步更新策略，一句话概括在下次DOM更新循环结束之后执行延迟回调。它主要是为了解决：例如一个data中的数据它的改变会导致视图的更新，而在某一个很短的时间被改变了很多次，假如是1000次，每一次的改变如果都将促发数据中的setter并按流程跑下来直到修改真实DOM，那DOM就会被更新1000次，这样的做法肯定是非常低效的。
而目前浏览器平台并没有实现nextTick方法，所以Vue.js 源码中分别用 Promise、MutationObserver、setImmediate 、setTimeout方式(Vue2.6.11)定义了一个异步方法nextTick，它接收的是一个回调函数，多次调用nextTick会将传入的回调函数存入队列中，当当前栈的任务都执行完毕之后才来执行这个队列中刚刚存储的那些回调函数，并且通过这个异步方法清空当前队列。
beforeCreate是new Vue()之后触发的第一个钩子，在当前阶段data、methods、computed以及watch上的数据和方法都不能被访问。
created在实例创建完成后发生，当前阶段已经完成了数据观测，也就是可以使用数据，更改数据，在这里更改数据不会触发updated函数。可以做一些初始数据的获取，在当前阶段无法与Dom进行交互，如果非要想，可以通过vm.$nextTick来访问Dom。
beforeMount发生在挂载之前，在这之前template模板已经被编译成了render function。而当前阶段虚拟Dom已经创建完成，即将开始渲染。在此时也可以对数据进行更改，不会触发updated。
mounted在挂载完成后发生，在当前阶段，真实的Dom挂载完毕，数据完成双向绑定，可以访问到Dom节点，使用$refs属性对Dom进行操作。一般可以在这个阶段进行Ajax请求，但需要注意的是服务端渲染时不支持mounted，需要放到created中。
beforeUpdate发生在更新之前，也就是响应式数据发生更新，虚拟dom重新渲染之前被触发，你可以在当前阶段进行更改数据，不会造成重渲染。
updated发生在更新完成之后，当前阶段组件Dom已完成更新。要注意的是避免在此期间更改数据，因为这可能会导致无限循环的更新。
beforeDestroy发生在实例销毁之前，在当前阶段实例完全可以被使用，我们可以在这时进行善后收尾工作，比如清除计时器。
destroyed发生在实例销毁之后，这个时候只剩下了dom空壳。组件已被拆解，数据绑定被卸除，监听被移出，子实例也统统被销毁。
Computed本质是一个具备缓存的watcher，依赖的属性发生变化就会执行回调。 适用于一些比较消耗性能的复杂计算或者是一些需要被频繁调用的计算。因为当表达式过于复杂时，在模板中放入过多逻辑会让模板难以维护，可以将复杂的逻辑放入计算属性中处理。
Watch没有缓存性，更多的是观察的作用，可以监听某些数据执行回调。当我们需要深度监听对象中的属性时，可以打开deep：true选项，这样便会对对象中的每一项属性进行监听。但是这样会带来性能问题，优化的话可以使用字符串形式监听，如果没有写到组件中，也就是使用vm.$watch来设置监听的时候，这个vm.$watch是会返回一个取消观察函数，调用这个函数就可以手动注销监听了。
当条件不成立时，v-if不会渲染DOM元素，v-show操作的是样式(display)，切换当前DOM的显示和隐藏。
（从Vue源码的角度上来看，v-if的判断应该是发生在template编译成render function的过程中）
一个组件被复用多次的话，也就会创建多个实例。本质上，这些实例用的都是同一个构造函数。如果data是对象的话，对象属于引用类型，会影响到所有的实例。所以为了保证组件不同的实例之间data不冲突，data必须是一个函数。
v-model本质就是一个语法糖，可以看成是:value + v-on方法的语法糖。 可以通过model属性的prop和event属性来进行自定义。原生的v-model，会根据标签的不同生成不同的事件和属性。
- text 和 textarea 元素使用
value属性和input事件； - checkbox 和 radio 使用
checked属性和change事件； - select 字段将
value作为 prop 并将change作为事件。
Vue 支持 2 种事件类型，原生 DOM 事件和自定义事件。
- 普通
DOM和组件上挂了.native修饰符之后，最终调用的还是原生的addEventListener()方法 - 组件上，
Vue实例上事件会调用原型上的$on、$emit、$off、$once等方法。
Vue模版编译，也就是compilte阶段，它其实就是将template转化为render function 的过程，它会经过以下三个阶段：
-
parse阶段将template字符串通过各种正则表达式生成一颗抽象语法树AST，在解析的过程中是通过while不断循环这个字符串，每解析完一个标签指针向下移动；并且用栈来建立节点间的层级关系，也就是用来保存解析好的标签头。 -
optimize阶段将生成的抽象语法树AST进行静态标记，这些被标记为静态的节点在后面的patch过程中会被跳过对比，从而达到优化的目的。标记的主要过程是为每个节点设置类似于static这样的属性，或者给根节点设置一个staticRoot属性表明这是不是一个静态根。 -
在进入到
generate阶段之前，说明已经生成了被静态标记过的AST，而generate就是将AST转化为render function字符串。
简单来说，diff算法有以下过程
- 先同级比较再比较子节点
- 先判断一方有子节点和一方没有子节点的情况。如果新的一方有子节点，旧的一方没有，相当于新的子节点替代了原来没有的节点；同理，如果新的一方没有子节点，旧的一方有，相当于要把老的节点删除。
- 再来比较都有子节点的情况，这里是
diff的核心。首先会通过判断两个节点的key、tag、isComment、data同时定义或不定义以及当标签类型为input的时候type相不相同来确定两个节点是不是相同的节点，如果不是的话就将新节点替换旧节点。 - 如果是相同节点的话才会进入到
patchVNode阶段。在这个阶段核心是采用双端比较的算法，同时从新旧节点的两端进行比较，在这个过程中，会用到模版编译时的静态标记配合key来跳过对比静态节点，如果不是的话再进行其它的比较。
Vue3.x借鉴了ivi算法和inferno算法。
它在创建VNode的时候就确定了其类型，以及在mount/patch的过程中采用位运算来判断一个VNode的类型，在这个基础之上再配合核心的Diff算法，使得性能上较Vue2.x有了提升。
因为diff算法是通过同层之间的树节点进行比较而并非对树进行逐层搜索遍历，所以时间复杂度只有O(n), 因此算是一个比较高效的算法了。
由于在浏览器中操作DOM是很昂贵的。频繁的操作DOM，会产生一定的性能问题。这就是虚拟Dom的产生原因。
Virtual DOM本质就是用一个原生的JS对象去描述一个DOM节点。是对真实DOM的一层抽象。(也就是源码中的VNode类，它定义在src/core/vdom/vnode.js中。)
VirtualDOM映射到真实DOM要经历VNode的create、diff、patch等阶段。
「key的作用是尽可能的复用 DOM 元素。」
新旧 children 中的节点只有顺序是不同的时候，最佳的操作应该是通过移动元素的位置来达到更新的目的。
需要在新旧 children 的节点中保存映射关系，以便能够在旧 children 的节点中找到可复用的节点。key也就是children中节点的唯一标识。
keep-alive可以实现组件的缓存，它允许组件之间切换不会被销毁。
主要是有include、exclude、max三个属性；前两个属性允许keep-alive有条件的进行缓存；max可以定义组件最大的缓存个数，如果超过了这个个数的话，在下一个新实例创建之前，就会将以缓存组件中最久没有被访问到的实例销毁掉。
它有两个生命周期，分别是activated/deactivated，用来得知当前组件是否处于活跃状态。
组件的调用顺序都是先父后子,渲染完成的顺序是先子后父。
组件的销毁操作是先父后子，销毁完成的顺序是先子后父。
加载渲染过程
父beforeCreate->父created->父beforeMount->子beforeCreate->子created->子beforeMount- >子mounted->父mounted
子组件更新过程
父beforeUpdate->子beforeUpdate->子updated->父updated
父组件更新过程
父 beforeUpdate -> 父 updated
销毁过程
父beforeDestroy->子beforeDestroy->子destroyed->父destroyed
父子组件通信
父->子props，子->父 $on、$emit
获取父子组件实例 $parent、$children
Ref 获取实例的方式调用组件的属性或者方法
Provide、inject 官方不推荐使用，但是写组件库时很常用
兄弟组件通信
Event Bus` 实现跨组件通信 `Vue.prototype.$bus = new Vue
Vuex
跨级组件通信
Vuex
$attrs、$listeners
Provide、inject
SSR也就是服务端渲染，也就是将Vue在客户端把标签渲染成HTML的工作放在服务端完成，然后再把html直接返回给客户端。
SSR有着更好的SEO、并且首屏加载速度更快等优点。不过它也有一些缺点，比如我们的开发条件会受到限制，服务器端渲染只支持beforeCreate和created两个钩子，当我们需要一些外部扩展库时需要特殊处理，服务端渲染应用程序也需要处于Node.js的运行环境。还有就是服务器会有更大的负载需求。
- 能不写在data中的数据不写在里面，因为data中的数据都会增加
getter和setter，会收集对应的watcher。 key值保证唯一- 如果需要用到
v-for给每项元素绑定事件时可以用到事件代理 - 在更多数的情况下，使用
v-if来代替v-show - 对于一些组件可以采用
keep-alive来进行缓存 - 使用路由懒加载，异步组件
- 第三方库按需引入
- 防抖节流
- 图片懒加载
- 将一些常用的方法封装成一个
library发布到npm上，然后在多个项目中引用 - 也会将一些公用的组件封装成一个单独的项目然后使用webpack打包发布到npm上
- 使用
loading或者骨架屏 - 使用
transition组件进行动画上的交互 - 封装一个
svg的组件来使用iconfont上的彩色图标，丰富页面。
- 压缩代码
- Tree Shaking 删除无用代码
- SplitChunks插件来抽离公共文件
- css代码分离
- 最明显的是在显示上，
hash模式的URL中会夹杂着#号，而history没有。 Vue底层对它们的实现方式不同。hash模式是依靠onhashchange事件(监听location.hash的改变)，而history模式是主要是依靠的HTML5 history中新增的两个方法，pushState()可以改变url地址且不会发送请求，replaceState()可以读取历史记录栈,还可以对浏览器记录进行修改。- 当真正需要通过
URL向后端发送HTTP请求的时候，比如常见的用户手动输入URL后回车，或者是刷新(重启)浏览器，这时候history模式需要后端的支持。因为history模式下，前端的URL必须和实际向后端发送请求的URL一致，例如有一个URL是带有路径path的(例如www.lindaidai.wang/blogs/id)，如果后端没有对这个路径做处理的话，就会返回404错误。所以需要后端增加一个覆盖所有情况的候选资源，一般会配合前端给出的一个404页面。
hash:
window.onhashchange = function(event){
// location.hash获取到的是包括#号的，如"#heading-3"
// 所以可以截取一下
let hash = location.hash.slice(1);
}一般建议放在mounted中。
首先，一个组件的 created 比 mounted 也早调用不了几微秒，性能没啥提高； 而且，等到异步渲染开启的时候，created 就可能被中途打断，中断之后渲染又要重做一遍，想一想，在 created 中做ajax调用，代码里看到只有调用一次，但是实际上可能调用 N 多次，这明显不合适。 相反，若把发ajax 放在 mounted，因为 mounted 在第二阶段，所以绝对不会多次重复调用，这才是ajax合适的位置.
Vue在两个for循环之前做了很多的预判。比如oldStartNode、oldEndNode、newStartNode、newStartNode这个对比。
- 响应式的原理不同
- 更加细致的静态标记