标准答案
- Options API 按选项分组，把 data、computed、watch、methods、生命周期分开写。简单组件读起来清楚，但复杂组件里同一个业务逻辑会分散在多个选项中。
- Composition API 按逻辑分组，可以把一个功能相关的 ref、computed、watch、方法和生命周期放在一起，复杂页面更容易拆分和维护。
- Composition API 更适合抽取 composable，例如 usePagination、useTableQuery、useFormSubmit，并且 TypeScript 推导通常更自然。
- Options API 仍然适合简单页面、老项目维护、团队成员更熟悉 Vue 2 写法的场景。
- 选择时不要只看新旧。简单组件可以保持 Options API，复杂业务状态、跨组件复用和强类型需求更适合 Composition API。
题目解析
这题不是让你否定 Options API，而是说明两种组织方式解决的问题不同。
Composition API 的优势在复杂度上升后更明显：逻辑可聚合、可抽取、类型更直接。
Composition API 也可能被滥用。如果 composable 没有明确输入输出，把太多全局状态塞进去，代码会比 Options API 更难追踪。
代码示例
同一个搜索列表逻辑，用组合式函数可以把分页、关键词和请求方法放在一起复用。
TypeScript
import { ref } from 'vue'
export function useSearchList() {
const keyword = ref('')
const page = ref(1)
const loading = ref(false)
async function search() {
loading.value = true
try {
page.value = 1
await fetchList({ keyword: keyword.value, page: page.value })
} finally {
loading.value = false
}
}
return {
keyword,
page,
loading,
search
}
}常见误区
- 只回答“Composition API 更先进”，说不出它解决了逻辑分散和复用问题。
- 把所有逻辑都抽成 composable，导致组件和组合式函数之间来回跳转。
- 认为 Options API 已经不能用。Vue 3 仍然支持 Options API。