前言
2023年了，距离vue3出世也好几年了，但目前依然很多项目是vue2，但vue3的趋势是不可避免的
大部分人都是从vue2学习，再用vue3，就接触到了组合式api，但对于组合式api不了解的人第一眼看上去会觉得：“什么玩意，乱七八糟的，选项式api多好，方法变量分的明明白白的。”，但对于大部分的人来说：“既然大家都在用，那我也跟着用”
但你去给你不会vue3的同事安利Composition Api亦或者说刚学vue的小白的时候，
对方来一局灵魂拷问：”为啥要用这个？好麻烦，好乱啊“。
这篇文章以对比的方式来阐述两种api的区别及好处
什么是组合式api
看看官方文档的说明
组合式 API (Composition API) 是一系列 API 的集合，使我们可以使用函数而不是声明选项的方式书写 Vue 组件。它是一个概括性的术语，涵盖了以下方面的 API：
- 响应式 API：例如
ref()和reactive()，使我们可以直接创建响应式状态、计算属性和侦听器。 - 生命周期钩子：例如
onMounted()和onUnmounted()，使我们可以在组件各个生命周期阶段添加逻辑。 - 依赖注入：例如
provide()和inject()，使我们可以在使用响应式 API 时，利用 Vue 的依赖注入系统。
再看看官方给出的一张图以及说明
简单来说：“代码分块不是按照data、methods、computed等来分，而是根据逻辑来分块，以往需要找到这块功能的相关逻辑需要各种切换滚动，找来找去，用了组合式api之后妈妈再也不怕我找不到相关逻辑代码了，并且挪动这块代码到别的文件，不需要重新组织代码，大大降低重构成本，大大提高代码的可阅读性。”
当然了，如果不理解组合式api为什么要这么设计，可能就会越写越乱，最终变成了一坨屎山，这时候这两种api的区别就是一个分好类的屎山和一个没分类的屎山
更好的逻辑组织及复用
在options Api中，基本都使用mixin来做一个混入，来实现一个逻辑复用，options api加上各种mixin注入，再莫名其妙调一个this.xxxx()方法，你甚至都不知道在哪里哪个文件定义过这个方法。但如果我们用hooks来替代mixin，再加上typescript ，就能非常容易追溯数据来源，这里再推荐一个hooks库，[vueuses]: https://vueuse.org/ 当然你可以根据自己的需求去写hooks以达到逻辑复用的目的
例如我之前的一篇文章：移动端下划滚动加载配合hooks使用
官方文档说明：Vue 2 的用户可能会对 mixins 选项比较熟悉。它也让我们能够把组件逻辑提取到可复用的单元里。然而 mixins 有三个主要的短板：
- 不清晰的数据来源：当使用了多个 mixin 时，实例上的数据属性来自哪个 mixin 变得不清晰，这使追溯实现和理解组件行为变得困难。这也是我们推荐在组合式函数中使用 ref + 解构模式的理由：让属性的来源在消费组件时一目了然。
- 命名空间冲突：多个来自不同作者的 mixin 可能会注册相同的属性名，造成命名冲突。若使用组合式函数，你可以通过在解构变量时对变量进行重命名来避免相同的键名。
- 隐式的跨 mixin 交流：多个 mixin 需要依赖共享的属性名来进行相互作用，这使得它们隐性地耦合在一起。而一个组合式函数的返回值可以作为另一个组合式函数的参数被传入，像普通函数那样。
基于上述理由，我们不再推荐在 Vue 3 中继续使用 mixin。保留该功能只是为了项目迁移的需求和照顾熟悉它的用户
更好的类型推导
官方说明：
近几年来，越来越多的开发者开始使用 TypeScript 书写更健壮可靠的代码，TypeScript 还提供了非常好的 IDE 开发支持。然而选项式 API 是在 2013 年被设计出来的，那时并没有把类型推导考虑进去，因此我们不得不做了一些复杂到夸张的类型体操才实现了对选项式 API 的类型推导。但尽管做了这么多的努力，选项式 API 的类型推导在处理 mixins 和依赖注入类型时依然不甚理想。
因此，很多想要搭配 TS 使用 Vue 的开发者采用了由 vue-class-component 提供的 Class API。然而，基于 Class 的 API 非常依赖 ES 装饰器，在 2019 年我们开始开发 Vue 3 时，它仍是一个仅处于 stage 2 的语言功能。我们认为基于一个不稳定的语言提案去设计框架的核心 API 风险实在太大了，因此没有继续向 Class API 的方向发展。在那之后装饰器提案果然又发生了很大的变动，在 2022 年才终于到达 stage 3。另一个问题是，基于 Class 的 API 和选项式 API 在逻辑复用和代码组织方面存在相同的限制。
相比之下，组合式 API 主要利用基本的变量和函数，它们本身就是类型友好的。用组合式 API 重写的代码可以享受到完整的类型推导，不需要书写太多类型标注。大多数时候，用 TypeScript 书写的组合式 API 代码和用 JavaScript 写都差不太多！这也让许多纯 JavaScript 用户也能从 IDE 中享受到部分类型推导功能。
简单来说：TS支持非常非常友好！！兄弟们！！喜欢用ts兄弟们直接上vue3+tsx写法，更舒服
更小的生产包体积
Composition Api对于代码压缩更友好，因为 <script setup> 形式书写的组件模板被编译为了一个内联函数，和 <script setup> 中的代码位于同一作用域。不像选项式 API 需要依赖 this 上下文对象访问属性，被编译的模板可以直接访问 <script setup> 中定义的变量，无需从实例中代理。
Tree-Sharking支持:很轻松的把无关的依赖项摇掉，传统Options Api配合main.js文件中的各种杂七杂八全局挂载，导致每个组件都很臃肿，即使你没有使用到你挂载的东西。本来this就很乱了，加上莫名其妙不知道在哪里定义了个东西挂载到this上，还得一通找
书写便利
在vue3.2以后的版本，新增了setup语法糖，
引入组件再也不需要声明，但在Options Api中要想组件不用声明只能挂载到全局
定义的变量也不需return，也不用担心this指向问题，配合reactive使用一眼就能看出是变量还是方法
总结
Composition Api解决了Options Api中的大部分痛点，写出可维护性高的代码一直以来都是每个人的追求，谁也不想被以后维护自己写过项目的人心里一顿骂吧，所以，一起拥抱Composition Api吧。