Vue 3 的组合式 API（Composition API）相比选项式 API（Options API）有什么优势？

1. 更好的逻辑复用与组织（Logical Reusability）

• Options API 的痛点：在 Options API 中，逻辑通常被分散在 data、methods、computed、watch 等选项中。当组件变得复杂时，同一个功能逻辑（例如“搜索用户”）的代码会被拆散在不同地方，导致维护困难（即“横向切片”问题）。虽然可以使用 Mixins 复用逻辑，但 Mixins 存在命名冲突、来源不清晰等缺点。
• Composition API 的优势：允许你将属于同一个逻辑关注点的代码（状态、计算属性、方法、生命周期钩子）组织在一起，封装成独立的函数（通常称为 Composables，如 useUserSearch）。这使得逻辑复用更加直观、灵活，且没有命名空间污染的问题。

2. 更灵活的代码组织方式

• Options API：强制按照固定的选项结构（data, methods…）组织代码。随着组件变大，开发者需要在文件的不同部分之间来回滚动以查看完整的功能逻辑。
• Composition API：采用“关注点分离”而非“选项分离”。你可以按照功能逻辑来组织代码。例如，所有与“表单验证”相关的代码可以写在一起，所有与“数据获取”相关的代码写在一起。这使得大型组件的可读性和可维护性显著提高。

3. 更强的 TypeScript 支持

• Options API：由于 this 的存在以及选项对象的动态特性，TypeScript 的类型推导往往比较复杂，经常需要显式定义类型或使用复杂的泛型工具。
• Composition API：基于普通的变量和函数，天然契合 TypeScript。不需要特殊的类型包装，自动推导能力极强，编写 TS 代码的体验非常流畅，几乎不需要额外的类型注解。

4. 更小的生产包体积（Tree-shaking）

• Options API：即使你没有使用某个选项（例如 watch），Vue 实例内部仍然需要包含处理该选项的逻辑代码，因为框架无法静态分析确定你是否会用到它。
• Composition API：所有的功能都是通过导入函数（如 ref, reactive, watch）使用的。如果你没有导入某个函数，打包工具（如 Webpack, Vite）就可以通过 Tree-shaking 将其从最终 bundle 中移除，从而减小文件体积。

5. 更高的灵活性

• Options API：受限于预定义的选项结构，某些高级场景（如动态添加响应式属性、复杂的条件逻辑初始化）实现起来比较别扭。
• Composition API：本质上是基于函数的编程范式，可以在任何地方调用响应式 API，不受生命周期或选项顺序的限制，能够应对各种复杂的架构需求。

代码对比示例

Options API (Vue 2 风格)

1export default {
2  data() {
3    return {
4      count: 0
5    }
6  },
7  computed: {
8    doubleCount() {
9      return this.count * 2
10    }
11  },
12  methods: {
13    increment() {
14      this.count++
15    }
16  }
17}

Composition API (Vue 3 风格)

1import { ref, computed } from 'vue'
2
3export default {
4  setup() {
5    const count = ref(0)
6    
7    const doubleCount = computed(() => count.value * 2)
8    
9    function increment() {
10      count.value++
11    }
12
13    // 返回给模板使用
14    return { count, doubleCount, increment }
15  }
16}

1<script setup>
2import { ref, computed } from 'vue'
3
4const count = ref(0)
5const doubleCount = computed(() => count.value * 2)
6function increment() {
7  count.value++
8}
9</script>

总结：应该选哪个？