Vue Composition API 和 Options API 有什么区别？怎么选择？

简化版

Options API 按 data、methods、computed 等选项组织代码，适合简单组件；Composition API 按业务逻辑组织代码，适合复杂组件、逻辑复用和 TypeScript。Vue3 不要求二选一，面试回答要强调“按复杂度和复用需求选择”。

详细版

Options API 的代码结构更直观：

export default {
  data() {
    return { count: 0 };
  },
  methods: {
    inc() {
      this.count++;
    },
  },
};

Composition API 更强调把同一业务逻辑放在一起：

const count = ref(0);
function inc() {
  count.value++;
}

如果组件很小，Options API 易读；如果一个组件里同时有筛选、分页、权限、请求状态等逻辑，Composition API 更容易抽成 usePagination、usePermission 这样的组合式函数。

完整版教学

一、两种 API 的核心差异是组织维度不同

Options API 是按“选项类型”组织代码：状态放 data，方法放 methods，派生值放 computed。这种结构对新手友好，因为每个选项位置固定。但当组件变复杂，同一业务逻辑会被拆散到多个选项里。

筛选逻辑：
  data       -> filterForm
  computed   -> filteredList
  methods    -> resetFilter
  watch      -> 监听筛选条件

Composition API 是按“业务逻辑”组织代码。筛选相关的状态、计算、监听、方法可以放在同一块，甚至抽到同一个函数里。这就是它更适合复杂组件的原因。

二、Options API 的优势是清晰和约定强

Options API 很适合页面不复杂、团队成员水平参差不齐、需要快速读懂结构的场景。你打开组件，看到 props、data、computed、methods，大概就知道每类代码在哪里。这种强约定降低了入门成本。

export default {
  props: ['id'],
  data() {
    return { loading: false, list: [] };
  },
  computed: {
    total() {
      return this.list.length;
    },
  },
};

如果一个组件只有 100 行左右，Options API 的分区反而很舒服。它的问题通常出现在 300 行以上的复杂组件：同一功能被切成多段，维护者要上下跳。所以不能把 Options API 简单说成“旧”，它仍然是 Vue 支持的稳定写法。

三、Composition API 的优势是逻辑复用和组合

Composition API 最大价值不是少写代码，而是让逻辑可以自然抽取。比如分页逻辑在 5 个列表页都要用，Options API 通常用 mixin，但 mixin 有命名冲突和来源不清的问题。 Composition API 可以写成显式导入的组合式函数。

function usePagination() {
  const page = ref(1);
  const pageSize = ref(20);
  const offset = computed(() => (page.value - 1) * pageSize.value);

  return { page, pageSize, offset };
}

使用处很清楚：

const { page, pageSize, offset } = usePagination();

这里的数字例子很直观：page=3、pageSize=20 时，offset=(3-1)*20=40。逻辑来源来自 usePagination，不会像 mixin 一样“凭空”多出字段。

四、TypeScript 下 Composition API 更自然

Options API 依赖 this，而 this 的类型推断在复杂 mixin、装饰器、插件扩展里容易变得绕。 Composition API 主要使用普通变量和函数，和 TypeScript 的类型推断更贴合。这也是 Vue3 项目大量采用 <script setup> 的原因。

<script setup lang="ts">
const props = defineProps<{
  id: string;
  pageSize?: number;
}>();

const count = ref<number>(0);
</script>

维度	Options API	Composition API
组织方式	按选项分组	按逻辑分组
逻辑复用	mixin、插件、组件	composable
TypeScript	`this` 类型较绕	普通函数推断更自然
入门体验	更直观	需要理解 ref/reactive
复杂组件	容易分散	更易聚合

五、Composition API 不等于所有代码都写在 setup 里

有些项目用了 Composition API 后，把 500 行逻辑都塞进 setup，这其实只是换了语法，没有改善结构。正确做法是按业务边界拆组合式函数。比如请求、表单、分页、权限、弹窗都可以独立。

UserList.vue
  -> useUserQuery()
  -> usePagination()
  -> usePermission()
  -> useDialog()

记忆钩子：Options API 是“按框子放代码”，Composition API 是“按事情放代码”。

拆分后，组件本体只负责组装和模板渲染。这能让复杂页面从“一个大文件”变成多个可测试、可复用的小逻辑块。

六、实际选择要看团队和组件复杂度

Vue3 同时支持两种 API，不需要把它们对立起来。小型页面、老项目维护、低复杂度后台表单，用 Options API 完全可以。复杂页面、跨组件逻辑复用、组件库、TypeScript 项目，更推荐 Composition API。

简单组件：
  Options API 成本低
复杂组件：
  Composition API 更好拆
可复用逻辑：
  composable 优先
老项目：
  渐进迁移，不必一次重写

面试官更想听到的是工程判断，而不是“Vue3 就必须 Composition API”。如果能补一句“Composition API 解决的是复杂逻辑组织和复用问题”，答案会更稳。

七、常见误区与追问

误区：Composition API 是为了完全替代 Options API。 Vue3 仍然支持 Options API，选择应看复杂度、团队习惯和复用需求。
误区：用了 Composition API 就一定更清晰。 如果所有逻辑都堆在 setup 里，仍然会变成大组件。
误区：Options API 不能做逻辑复用。 它可以用 mixin、插件、组件抽象，只是大型项目里来源和命名冲突更难控制。
追问：为什么 Composition API 更适合 TypeScript？ 它主要使用普通变量和函数，减少 this 上下文推断带来的复杂度。
追问：组合式函数命名有什么约定？ 通常以 use 开头，例如 useRequest、usePagination，表示可组合的状态逻辑。
追问：老项目怎么迁移？ 可以新组件优先用 Composition API，旧组件按业务修改逐步迁移，不需要全量重写。

八、加强记忆

这题按“组织维度”回答最稳：Options API 按选项组织，适合简单清晰；Composition API 按逻辑组织，适合复杂页面、逻辑复用和 TypeScript。再用分页 composable 举例，说明它不是语法换皮，而是把可复用业务逻辑从组件里抽出来。

简化版

详细版