Vue面试深问：组合式API与选项式API的设计权衡

Vue选项式API与组合式API：核心定位与设计初衷对比

选项式API（Options API）作为Vue 2时代的原生方案，其设计基因天然倾向于面向新手、约定优先。

它借助data/methods/computed/watch这些固定选项来拆分代码，利用框架内置规则自动完成职责划分。这种做法的优势非常明显：入门门槛被降到最低，早期Vue生态、各类业务组件以及老项目几乎都建立在这样的基础之上。

而组合式API（Composition API）作为Vue 3主推的新方案，其使命更侧重于面向复杂业务、逻辑复用。基于setup配合组合函数（ref/reactive/computed/watch等）实现，核心要解决的是大型组件逻辑碎片化、跨组件逻辑复用困难、类型支持薄弱这三大长期存在的痛点。

需要强调的是，两者并非非此即彼的替代关系，而是互补选型。Vue官方也一直承诺长期兼容两套写法，具体选择完全取决于实际场景。

设计权衡深度解析

代码组织层面

选项式API：

它按照功能类型来划分代码（数据归数据、方法归方法、计算属性归计算属性、生命周期归生命周期）。这种组织方式能够做到结构统一、一目了然，新手阅读毫无障碍，团队统一规范的成本也很低。

但问题随之而来：在复杂组件中，同一业务逻辑会被拆散到不同的选项里。比如一个表单校验逻辑，可能散落在data、methods、watch三个地方。尤其当需要在不同区域间来回跳转阅读时，这种成本会非常高。组件越是臃肿，维护起来就越让人头疼。

组合式API：

它按照业务逻辑来聚合代码——将同一功能的状态、方法、监听全部写在一起。这样做带来的优势是高内聚，复杂业务模块边界清晰，长组件的可读性和可维护性得到大幅提升。

然而，硬币的另一面是：它没有强制格式约束，如果编码不规范，很容易导致代码混乱。因此它对开发者的编码规范要求更高，这也正是不少公司（如阿里）会制定前端开发格式规范的原因所在。

逻辑复用

这是两套API最核心的设计差异，没有之一。

选项式API依赖mixin来复用通用逻辑。但这种方案存在原生缺陷：命名冲突、隐式依赖、合并规则不透明、多mixin嵌套后溯源困难……这些问题决定了它不适合在中大型项目中大规模使用。

而组合式API将复用逻辑抽离成独立组合函数（自定义hooks） 来复用。它基于函数作用域隔离状态，显式导入、显式使用，不存在命名污染。同时支持参数传递、返回状态，复用起来既灵活又能溯源，是Vue官方推荐的逻辑复用方案。

TypeScript 支持

选项式API基于对象选项声明，类型推导存在短板，复杂场景下需要额外类型声明，整体的类型体验只能说一般。

而组合式API天然基于ES函数编写，与TypeScript类型系统完美契合，变量和函数的类型推导精准到位。对于大型工程化和TS项目而言，它是不二之选。

1分钟精简口述版

Vue的选项式API和组合式API，实际上是Vue针对不同场景、不同复杂度设计的两套方案，各有取舍，不存在绝对优劣。

选项式API依靠固定选项划分代码，上手简单、规范统一，适合简单页面和老项目。但复杂组件中逻辑会分散，mixin复用存在隐患。

组合式API以setup和组合函数为核心，按业务逻辑聚合代码，自定义hooks复用更干净，TypeScript支持也更优秀，更适配大型复杂项目。

简单组件和快速开发场景，选项式API仍然是最顺手的方案。而复杂业务、需要逻辑复用、TypeScript项目，则应该选择组合式。在实际开发中，很多人也会根据业务场景灵活混用。

说到底，二者没有优劣之分，只有场景适配。组合式API虽然借鉴了React Hooks的函数复用思想，但结合Vue的响应式系统做了差异化设计，形成了自身的特色。