1.5 选项式 API 与组合式 API 的定位与选型

Vue 3 提供了两种写组件的方式：选项式 API（Options API） 和组合式 API（Composition API）。它们不是“谁取代谁”的关系，而是应对不同复杂度场景的两套工具，可以共存、可以混用，但理解各自的定位会让你的代码组织更清晰。

选项式 API：按“角色”组织代码

选项式 API 是 Vue 2 时代延续下来的经典写法，用 data、methods、computed、watch、mounted 等固定选项来描述组件：

export default {
  data() {
    return { count: 0 }
  },
  computed: {
    double() { return this.count * 2 }
  },
  methods: {
    increment() { this.count++ }
  },
  mounted() {
    console.log('组件挂载了')
  }
}

核心特点：每个选项里放一类东西——数据都在 data 里，方法都在 methods 里，计算属性都在 computed 里。这种分组方式非常直观，尤其对新手友好：你只要按模板上的“填空”思维，把对应的代码填进对应的选项即可。

适用场景：

逻辑简单、组件规模小的项目。
团队习惯 Vue 2 写法，迁移成本低。
快速原型、培训教学，因为概念清晰、模式固定。

组合式 API：按“功能”组织代码

组合式 API 是 Vue 3 新增的写法，核心是一个 setup 函数（或更推荐的 <script setup> 语法糖），你可以用 ref、reactive、computed、watch、onMounted 等函数自由组合逻辑：

<script setup>
import { ref, computed, onMounted } from 'vue'

const count = ref(0)
const double = computed(() => count.value * 2)
function increment() { count.value++ }

onMounted(() => {
  console.log('组件挂载了')
})
</script>

核心特点：所有相关逻辑可以自然聚拢在一起——一个功能的数据、计算属性、方法和生命周期钩子，可以写在相邻的几行代码中，不再被“选项”强行拆散。

适用场景：

复杂组件，单个组件内包含多个独立的业务逻辑块。
逻辑复用需求强，可以将相同逻辑抽成自定义 hooks，随处调用。
需要强 TypeScript 类型推导，组合式 API 的类型推断明显更好。
准备向服务端渲染（Nuxt 3 等）或跨端开发扩展，这些生态更倾向于组合式 API。

两者的定位与选型建议

选项式 API 不会消失：Vue 3 完全兼容选项式写法，官方明确表示不会废弃它。如果你在维护老项目，或者组件足够简单，继续使用选项式完全没有问题。
组合式 API 是未来的主推方向：Vue 3 的新特性（如响应式语法糖、<script setup>、defineProps 解构等）大多基于组合式 API；新的官方库（Pinia、Vue Router 的 composition 用法）也更偏向组合式风格。
中小项目快速启动，可用选项式：比如几个页面的后台活动页，逻辑不复杂，选项式更符合“直接填表”的心智模型。
中大型项目、逻辑复用需求强，果断选择组合式：它能有效避免“同一个功能的代码散落在 data、methods、mounted 四处”的问题，让维护者一眼看清某个功能需要哪些变量和方法。

一个真实的心理落差：很多从选项式转到组合式的开发者，起初会觉得“需要手动 ref、脑子多转一道”，但用过几次后就会发现：“以前我在 data 里塞了一堆属性，又在 methods 里一堆方法，每次改功能都要上下来回跳；现在全在一块了，真香。”

团队统一风格优先：一个项目内部不建议频繁混用两种写法，除非是为了渐进式过渡。推荐在 eslint 配置中约定一种默认风格，保持代码一致性。

简单来说，会用选项式够你干活，学会组合式让你把活干得更聪明。根据项目阶段和团队状况挑选即可，Vue 本身没有“强推”任何一个，这恰恰是它渐进理念的延伸。