Vue3 组合式 API vs Options API：到底该怎么选？

二月龙
2 阅读4分钟

Vue3 组合式 API vs Options API：到底该怎么选？

Vue 3 发布之后，最让开发者纠结的问题之一就是：我该用组合式 API（Composition API），还是继续用熟悉的 Options API？

本文不站队、不制造焦虑，从设计理念、适用场景、真实开发体验三个维度，帮你做出适合自己的选择。

一、先给结论：怎么选？

一句话总结：

  • 新手 / 简单项目 / 维护老代码 → Options API
  • 中大型项目 / 复杂逻辑 / 长期维护 → 组合式 API

如果你赶时间，记住这句话就够了。下面我们展开讲原因。

二、两种 API 长什么样？

Options API（选项式）

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

特点：按“选项”组织代码，data、methods、computed泾渭分明。

组合式 API（组合式）

import { ref, computed, onMounted } from 'vue'

export default {
  setup() {
    const count = ref(0)
    const double = computed(() => count.value * 2)

    function increment() {
      count.value++
    }

    onMounted(() => {
      console.log('mounted')
    })

    return { count, double, increment }
  }
}

在 <script setup>语法糖下更简洁：

<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('mounted')
})
</script>

特点：按“逻辑关注点”组织代码，而不是按选项类型。

三、核心差异对比

维度Options API组合式 API
学习曲线✅ 低，直观⚠️ 稍高，需理解响应式原理
代码组织❌ 按选项拆分✅ 按功能聚合
逻辑复用❌ mixins（易冲突）✅ Composition Functions
TypeScript 支持⚠️ 一般✅ 极佳
代码压缩❌ 较差✅ 更好
心智负担✅ 初期低⚠️ 初期略高
长期维护❌ 复杂组件难维护✅ 可维护性更强

四、Options API 的优势与局限

✅ 适合的场景

  • Vue 初学者
  • 后台管理系统 CRUD 页面
  • 生命周期短的小项目
  • 维护 Vue2 老代码

✅ 优点

  • 结构固定，团队容易统一风格
  • 模板驱动，直觉强
  • this.xxx随手可用

❌ 痛点

1. 逻辑分散（跳来跳去）

一个功能的代码被拆到不同地方：

data() { /* 状态 */ },
methods: { /* 行为 */ },
computed: { /* 派生 */ }

当组件变大时，阅读成本急剧上升。

2. mixins 的坑
  • 命名冲突
  • 来源不清晰
  • 难以追溯
mixins: [aMixin, bMixin] // a 和 b 都有 count？
3. TS 支持不友好

this的类型推导困难，需要大量类型声明。

五、组合式 API 为什么是未来？

✅ 真正的优势

1. 逻辑聚合（同一个功能在一起）
// 用户逻辑
function useUser() {
  const user = ref(null)
  const loading = ref(false)

  async function fetchUser() {
    loading.value = true
    user.value = await api.getUser()
    loading.value = false
  }

  return { user, loading, fetchUser }
}

在组件中使用：

const { user, loading, fetchUser } = useUser()

✅ 高内聚、低耦合

2. 逻辑复用像搭积木
const { data, loading } = useFetch('/api/list')
const { isMobile } = useDevice()
const { theme } = useTheme()

这是 React Hooks 式的体验，但更符合 Vue 的响应式模型。

3. TypeScript 原生友好
const count = ref<number>(0) // 类型自动推导

没有 this，没有隐式上下文，类型一目了然。

4. 更好的代码压缩

Options API 依赖字符串键名（data、methods），难以压缩；

组合式 API 使用变量名，构建工具更容易优化。

⚠️ 不是没有代价

  • 需要理解 ref / reactive / toRefs
  • 需要适应“函数式思维”
  • 初期写小组件会感觉“啰嗦”

但这些成本，在大项目中会被成倍赚回来。

六、真实项目中的推荐策略

✅ 新项目（Vue3）

首选组合式 API + <script setup>

理由：

  • 官方主推
  • 生态（Pinia、VueUse）全面拥抱
  • 长期维护成本低

👉 即使你是新手，也值得直接上手组合式 API。

✅ 老项目（Vue2 / Vue3 + Options）

  • 不改旧代码
  • 新组件用组合式 API
  • 逐步迁移，而非一次性重构

✅ 团队规范建议

团队情况建议
新手为主Options API + 少量组合式
混合经验组合式 API，封装常用 hooks
全栈 / TS 重度组合式 API + strict TS
维护老系统Options API 为主

七、常见误区澄清

❌ “组合式 API 比 Options API 高级”

不是高级，只是更适合复杂场景。

简单页面用 Options API 完全没问题。

❌ “以后 Options API 会被删除”

不会。

Vue 官方明确承诺：Options API 长期支持。

❌ “必须全部用 Composition API”

不是非黑即白。

你可以在一个组件中混用（虽然不推荐）：

export default {
  data() {},
  setup() {}
}

八、来自官方的态度

Evan You 的态度很明确：

Options API 不会消失，但 Composition API 是未来的方向。

Vue 生态的新工具（Pinia、VueUse、Nuxt 3）几乎都基于组合式 API。

九、最终建议

如果你是：

  • 🧑🎓 刚学 Vue：先懂 Options API，再学组合式 API
  • 👨💻 日常开发：新项目直接用组合式 API
  • 🏢 技术负责人：制定规范，鼓励组合式 API + hooks 封装
  • 🛠 维护老项目：稳定优先，渐进升级

记住一句话：

Options API 是“好上手的工具”，

组合式 API 是“能打持久战的工具”。

十、写在最后

选 API，本质上是在选思维方式：

  • Options API：面向对象 + 模板思维
  • 组合式 API：函数式 + 逻辑复用思维

Vue3 给了你选择权，而不是强制你改变。

理解差异，按需选择，才是成熟开发者的做法。

avatar
文章
阅读
粉丝