[!info] related notes

• 所属 MOC: Vue 基础 MOC
• 对比: Composition API vs Options API
• SFC: script setup
• 路线: Vue 学习路线

Vue Options API

一句话定义

Options API 用预定义的组件选项组织代码：

• data
• computed
• methods
• watch
• props / emits
• lifecycle hooks

其主轴是：

这段逻辑属于哪个组件选项？

最小示例

<script>
export default {
  data() {
    return { qty: 0 }
  },
  computed: {
    label() {
      return this.qty < 5 ? '偏低' : '正常'
    },
  },
  methods: {
    increment() {
      this.qty++
    },
  },
}
</script>

优势

Options API 提供较强的结构 guard rails：

state → data
derived state → computed
actions → methods
side effects → watch/lifecycle

对于小到中型组件，这种固定结构往往清楚且容易 onboarding。

复杂组件里的边界

当同一个 feature 同时涉及 state、computed、watch、lifecycle 与 methods 时，其逻辑会分散到多个 option。

这也是 Composition API 更适合复杂 feature 聚合与 composable 抽取的原因之一。

完整关系见 Composition API vs Options API。

TypeScript

Options API 支持 TypeScript。

使用 defineComponent() 等方式可以获得类型推导，但在复杂 mixin / dependency injection 等场景里，Composition API 往往更贴近 TypeScript 的自然推导模型。

Options API 没有被废弃

Vue 官方没有计划废弃 Options API。

所以：

读懂 Options API 仍然是 Vue 基础能力。

已有稳定代码也不需要因为 Vue3 就机械迁移。

常见误区

data 写成共享对象

组件实例需要自己的 state 对象；Options API 的 data 应返回实例级数据。

用“旧 API”贬低 Options API

它是持续支持的模型，不是 legacy-only syntax。

把大型组件的组织问题误认为 API 本身的问题

有时真正需要的是拆组件、拆 domain 或抽 composable，而不是只换语法。

学习检查

1. Options API 的组织主轴是什么？
2. 为什么小组件里 Options API 往往很直观？
3. 一个 feature 同时跨 data/computed/watch/methods 时，会出现什么组织成本？
4. 为什么 Options API 支持 TypeScript，但 Composition API 常有更自然的推导体验？
5. 为什么稳定 Options API 代码不应该被机械重写？