4.3 Options 与 Composition 两套 API

4.3 Options 与 Composition 两套 API

本节摘要：Vue 提供 Options API 与 Composition API 两套组件逻辑写法。前者按 data/methods 分组、上手直观，后者按功能点组织、逻辑复用更顺。本节对比两者给出选型判断，并呼应 React 函数组件与 Hooks 的角色。

本节阅读目标
阅读完本节，你应当能够：

1. 用两种 API 写出同一个组件并说清结构差异。
2. 说出 Composition API 在逻辑复用上的优势。
3. 判断什么时候选 Options、什么时候选 Composition。

一、两套写法各画一张脸

同一个"计数"组件用两套 API 各写一次。

Options API：

<script>
export default {
  data() {
    return { count: 0 };
  },
  methods: {
    add() { this.count += 1; },
  },
};
</script>
<template><button @click="add">次数 {{ count }}</button></template>
​

Composition API（script setup）：

<script setup>
import { ref } from 'vue';
const count = ref(0);
function add() { count.value += 1; }
</script>
<template><button @click="add">次数 {{ count }}</button></template>
​

Options 把所有数据放 data、方法放 methods、生命周期放各钩子，是一种"按类型归类"的组织；Composition 则把围绕一个功能点的状态、方法、副作用写在一起，是一种"按功能归类"的组织。

二、组织方式背后的取舍

Options 的门槛低，结构一眼可读，方便看"这个组件有哪些数据、哪些方法"，适合简单组件与新手。但一旦逻辑变多，同一个跨国流程的方法被 data/methods/watch 拆散，读起来得跨片找。Composition 允许把相关逻辑靠在一起、再抽成可复用的组合式函数，对应 5.5 节讲的复用抽象，复杂应用更顺手。

三、同一段逻辑，两套组织法的体感差别

空谈组织方式不够直观，用一个"带搜索过滤的列表"各写一遍，最能体会差别。Options 版本把所有东西按类型归拢：

<script>
export default {
  data() { return { keyword: '', list: [], filtered: [] }; },
  computed: {
    doFilter() {
      return this.list.filter((x) => x.includes(this.keyword));
    },
  },
  methods: { load() { this.list = ['林','月','风']; } },
  mounted() { this.load(); },
};
</script>
​

Composition 版本把同一功能点收拢在一个区域：

<script setup>
import { ref, computed, onMounted } from 'vue';
const keyword = ref('');
const list = ref([]);
const filtered = computed(() => list.value.filter((x) => x.includes(keyword.value)));
function load() { list.value = ['林', '月', '风']; }
onMounted(load);
</script>
​

看到最后一组对应就明白了：Options 把 filtered、list、keyword 这三个围绕"搜索"的量，被按 data/computed 分到两处；Composition 则让它们全挨在一起，谁依赖谁一眼能看出。逻辑一多，这种"按功能靠拢"的价值就体现出来——你不用在文件两端来回跳着拼装一段完整的心智。

四、图：两套 API 的组织差异

图：Options 按类型分组 vs Composition 按功能分组

五、怎么选：比稿判断

• 新项目、逻辑会增长：倾向 Composition，先手就把它组织好。
• 简单演示、快速原型：Options 更省心。
• 旧代码：先读得懂 Options 再决定是否迁移，别为了时髦强行重写。

对应于 React：Options 的体感有点像比较好上手的写法，而 Composition 与 React 函数组件 + Hooks 的"把逻辑抽成可复用单元"是同类的走向。

判断时先问自己一句"这份逻辑以后要不要给别的组件用"：答案是要，Composition 的组合式函数搬出来就复用；答案只是本组件内的简单改数，Options 就已足够。别为了"新一点"而选 Composition——它真正的优势只在逻辑要跨组件复用时才兑现，日常小改反而多绕一层思考成本。

六、常见坑

• Composition 里忘了 .value：脚本中 ref 要用 .value，模板里自动解包，注意边界。
• Options 里 this 指向：方法里用 this 访问数据，别解构出来用会丢绑定。
• 两者混用的边界：一个组件尽量统一一套，别一半一半搅浑。

本节要点回顾

• 两套组织法：Options 按类型、Composition 按功能。
• 取舍：简单省心选 Options，增长易复用选 Composition。
• 对应 React：Composition 与 Hooks 走向同源。
• 三个坑：ref 的 .value、this 绑定、别两套混用。

无论哪套 API，背后都稳稳站着同一个响应式系统。下一节展开它：数据绑定与响应式原理，看 ref/reactive 与依赖追踪怎么让"改数据界面跟着变"落地。