如果你对如何通过组合式 API 使用 Vue 感兴趣，可以切换页面左侧边栏上方的 API 偏好到组合式 API，然后重新从头阅读指引。

为什么要有组合式 API？

更好的逻辑复用

组合式 API 最基本的优势是它使我们能够通过组合函数来实现更加简洁高效的逻辑复用。它解决了所有mixins的缺陷，那是选项式 API 中一种逻辑复用机制。

组合式 API 提供的更多逻辑复用可能性孵化了一些非常棒的社区项目，比如 VueUse，一个不断成长的工具型可组合函数集合。组合式 API 还为其他第三方状态管理库集成 Vue 的响应式系统提供了一套简洁清晰的机制，例如 RxJS。

更灵活的代码组织

许多用户都喜欢选项式 API，因为在默认情况下就能够写出有组织的代码：任何东西都有其对应的选项来管理。然而，选项式 API 在单个组件的逻辑复杂到一定程度时，也面临了一些无法忽视的限制。这些限制主要体现在需要处理多个逻辑关注点的组件中，在许多 Vue 2 已经上线的生产应用中可以看到这一点。

我们以 Vue CLI GUI 中的文件浏览器组件为例：这个组件承担了以下几个逻辑关注点：

• 追踪当前文件夹的状态，展示其内容
• 处理文件夹的相关操作(打开、关闭和刷新)
• 支持创建新文件夹
• 可以切换到只展示收藏的文件夹
• 可以开启对隐藏文件夹的展示
• 处理当前工作目录中的变更

这个组件最原始的版本是由选项式 API 写成的。而如果用组合式 API 重构这个组件，将会变成：

现在与同一个逻辑关注点相关的代码被归为了一组：我们无需再为了一个逻辑关注点在不同的选项块间来回滚动切换。此外，我们现在可以不费吹灰之力地将这一组代码移动到一个外部文件中，不再需要为了抽象而重新组织代码，大大降低了重构成本，这在长期维护的大型项目中非常关键。

更好的类型推导

近几年来，越来越多的开发者开始使用TypeScript书写更健壮可靠的代码，TypeScript还提供了非常好的 IDE 开发支持。然而选项式 API 是在 2013 年创建的，那时并没有想到需要进行类型推导。因此我们做了一些荒谬复杂的类型体操来实现对选项式 API 的类型推导。但尽管做了这么多的努力，选项式 API 的类型推导仍然无法适配混入和依赖注入。

因此，很多想要搭配 TS 使用 Vue 的开发者采用了由vue-class-component提供的 Class API。然而，基于 Class 的 API 非常依赖 ES 装饰器，在 Vue 2019 年开发完成后，它仍是一个仅处于 vue 2 的语言功能。我们认为将这样一种不稳定的方案作为官方 API 的一种实现形式风险过高，在那之后装饰器提案还进行了一些较大的变动，在书写这篇文档时仍未到达 vue 3。另外，基于 Class 的 API 和选项式 API 在逻辑复用和代码组织方面有相同的限制。

相比之下，组合式 API 主要利用基本的变量和函数，它们本身就是类型友好的。用组合式 API 重写的代码可以享受到完整的类型推导，不需要书写太多类型标注。大多数时候，用 TypeScript 书写的组合式 API 代码和用 JavaScript 写都差不太多！这也同样让许多纯 JavaScript 用户能从 IDE 中享受到部分类型推导功能。

vue-class-component官方文档：https://class-component.vuejs.org

vue-class-component是 vue 的官方库，作用是用类的方式编写组件。vue2.x 对 TS 的支持并不友好，所以 vue2.x 跟 TS 的整合，通常需要基于vue-class-component来用基于 class（类）的组件书写方式。然后现在 vue3.x 已出，对 TS 很友好的支持，所以使用 vue3.x ，不需要引用此 API。

生产包体积更小

搭配使用组合式 API 比等价情况下的选项式 API 更高效，对代码压缩也更友好。这是由于;形式书写的组件模板被编译为了一个内连函数，和中的代码位于同一作用域。不像选项式 API 需要依赖this上下文对象访问属性，被编译的模板可以直接访问中定义的变量，无需一个代码实例从中代理。这对代码压缩更友好，因为变量的名字可以变得更短，但对象的属性名则不能。

与选项式 API 的关系

组合式 API 是否覆盖了所有场景？

对于有状态的逻辑来说，的确如此。当使用组合式 API 时，只需要用到一小部分选项：props，emits，name和inheritAttrs。如果使用，那么inheritAttrs应该是唯一一个需要用额外的块书写的选项了。

如果你在代码中只使用了组合式 API(以及上述必需的选项)，得益于编译时标记你可以减小生产包大概几 kb 左右的体积，因为丢掉了 Vue 之中关于选项式 API 的所有代码。注意这也会影响你依赖中的 Vue 组件。

可以同时使用两种 API 吗？

可以。你可以在一个选项式 API 组件中使用setup()选项。

然而，我们只推荐你在就旧项目中这样使用。它们长期基于选项式 API 开发、又可能想要集成新的功能，或是想要集成基于组合式 API 的第三方库。

选项式 API 会被废弃吗？

与 Class API 的关系

我们不再推荐在 Vue 3 中使用 Class API，因为组合式 API 提供了很好的TypeScript集成，并具有额外的逻辑重用和代码组织优势。

和 React Hooks 相比

组合式 API 提供了和 React Hooks 相同级别的逻辑组织能力，但它们之间有着一些重要的区别。

React Hooks 在组件每次更新时都会重新调用。这就产生了一些即使是经验丰富的 React 开发人员也会感到困惑的问题。这也带来了一些性能问题，严重影响开发的体验。下面一些例子

• Hooks 有严格的调用顺序，并不可以写在条件分支中。
• React 组件中定义的变量会被一个钩子函数闭包捕获，若开发者传递了错误的依赖数组，它将保持不变。这导致了 React 开发者非常依赖 ESLint 规则以确保传递了正确的依赖，然而，这些规则往往不够智能，保持正确的代价过高，在一些边缘情况时会遇到令人头疼的、不必要的报错信息。
• 昂贵的计算需要使用useMemo，这也需要传入正确的依赖数组。
• 在默认情况下，传递给子组件的事件处理函数会导致子组件进行不必要的更新。子组件默认更新，并需要显式的调用useCallback作优化。这几乎是必需的，因此同样需要正确的依赖数组。忽视这一点会导致默认情况下对应用程序进行过度渲染，并可能在不知不觉中导致性能问题。
• 要解决变量闭包导致的问题，再结合并发功能，使得很难推理出一段钩子代码是什么时候运行的，并且很不好处理需要横跨多个渲染(通过 useRef)的可变状态。

相比起来，Vue 的组合式 API：

• 仅调用setup()或的代码一次。这使得代码能更好地与 JavaScript 的习惯性使用的直觉结合起来，因为不需要担心闭包变量的问题。组合式 API 也并不限制调用顺序，还可以有条件地进行调用。
• Vue 的响应性系统运行时会自动收集计算属性和侦听器的依赖，因此无需我们手动声明依赖。
• 无需手动缓存回调函数来避免不必要的组件更新。总而言之，Vue 细粒度的响应性系统确保了组件尽在需要的时候更新。对 Vue 开发者来说几乎不怎么需要对子组件更新进行手动优化。

我们承认 React Hooks 的创造性，它是组合式 API 的一个主要灵感来源。然而，它的设计也确实存在上面提到的问题，而 Vue 的响应性模型恰好提供了绕过了它们。