[!info] related notes

• 所属 MOC: Vue MOC
• 上位主题: vue3
• 依赖基础: Vue 响应式系统
• 相关主题: vueuse, pinia

Vue Composition API

Composition API 是 Vue3 推荐的逻辑组织方式。它把组件代码从“按选项分类”切换为“按功能聚合”。

一句话定义

如果说 Options API 是把代码分散到 data、methods、computed 这些栏目里，那么 Composition API 是把同一件业务相关的状态、派生值和操作放在一起。

它解决什么问题

• 复杂组件里，相关逻辑不再被切碎到不同配置项里
• 逻辑复用可以通过 composable 直接抽函数完成
• TypeScript 推导与类型组织更自然
• 更适合写中大型组件和可复用业务逻辑

最常见的使用形式

现在的主流组合是：Vue3 + Composition API + script setup。

<script setup lang="ts">
import { computed, ref } from 'vue'

const count = ref(0)
const double = computed(() => count.value * 2)

function increment() {
  count.value++
}
</script>

和 Options API 的核心差异

• Options API 按配置项分区
• Composition API 按功能聚合
• Options API 更像“组件配置”
• Composition API 更像“响应式函数式组织方式”

什么时候特别适合用它

• 表单逻辑、请求逻辑、分页逻辑、权限逻辑需要复用时
• 组件很大，状态和方法已经按功能分不清时
• 你希望把业务逻辑提炼到 useXxx() composable 时

常见组成部分

• 响应式状态：ref、reactive
• 派生值：computed
• 副作用：watch、watchEffect
• 生命周期钩子：onMounted、onUnmounted 等
• 组合式函数：useRequest、usePagination、useUser 之类的 composable

常见误区

• 以为 Composition API 只是把代码从 Options API 改成另一种语法
• 组件里什么都往 setup() 里堆，但没有按功能分段
• 逻辑复用时继续依赖过重的 mixin，而不是抽 composable

一句判断题

当你关心的是“某个功能需要哪些状态、派生值和动作”，而不是“这段代码属于 data 还是 methods”，你就已经在用 Composition API 的思维了。

面试要点

来自 vue-composition-api-vs-options-api-interview-question 的面试视角整理。

一句话回答

Options API 是按 data、methods、computed 这类配置项分类组织代码，Composition API 则更强调把同一功能相关的状态、派生值和操作放在一起。

最稳的回答主线

Options API

• 上手直观
• 小组件里结构清晰
• 复杂组件里相关逻辑容易分散

Composition API

• 更适合按功能聚合逻辑
• 更适合抽 composable 做复用
• 在复杂业务和 TypeScript 场景里通常更顺手

面试里一句很稳的话

Vue3 并不是废弃了 Options API，而是给了更适合复杂组件组织的新选择。

最短记忆方式

Options API 按类别拆代码，Composition API 按功能聚合代码。

Related notes

• Vue MOC