1.重构响应式系统，使用Proxy替代Object.defineProperty，使用Proxy优点：
可以直接监听形参类型的数据变化
监控的目标是对象本身，不需要像Object.defineProperty那样遍历每个属性，有一定的性能提升
可以拦截apply、ownKeys、has等13个方法typescript代码复用，但Object.defineProperty不能
直接添加/删除对象属性
2. 新的 Composition API，更好的逻辑重用和代码组织 3. 构建虚拟 DOM
模板编译时的优化，将一些静态节点编译成常量
槽优化，将槽编译成惰性函数，将槽渲染的决定权交给子组件
模板中内联风暴的提取和复用（原来内联函数每次渲染都会重新生成）
4.代码结构调整，更容易Tree shake，体积更小
5. 用 Typescript 替换 Flow
为什么会出现新的 Composition API，它能解决什么问题？
在Vue2.0中，随着功能的减少typescript代码复用，组件变得越来越复杂，难以维护。 无法维护的根本原因是Vue的API设计诱导开发者使用watch、compute、methods选项来组织代码，而不是实际的业务逻辑。
另外，Vue2.0缺乏一种相对简单且低成本的机制来完成逻辑复用。 虽然minxis可以完成逻辑复用，但是当mixin较多时，会导致无法找到对应的数据、计算或方法源。 对于该 mixin，使得类型推断变得不可能。
所以Composition API的出现主要是为了解决Option API带来的问题。 首先是代码组织的问题。 Composition API允许开发者按照业务逻辑来组织自己的代码，让代码具有更好的可读性和可扩展性，也就是说，当下一个开发者接触到一段不是自己写的代码时，他可以更好地利用代码的组织来推演实际的业务逻辑，或者根据业务逻辑更好地理解代码。
二是实现代码的逻辑抽取和复用。 当然，mixin 也可以实现逻辑抽取和复用，但是正如上面提到的，当多个 mixin 作用于同一个组件时，很难看出属性来自于那个 mixin ，来源不明。 另外，多个mixin的属性存在变量命名冲突的风险。 Composition API 正好解决了这两个问题。
