Vue3 Composition API vs Options API对比

Options API痛点

1. 逻辑分散：同一功能的数据(data)、方法(methods)、计算属性(computed)、生命周期分散在不同选项中

   export default {
     data() { return { count: 0, users: [], loading: false }; },
     methods: { fetchUsers() {...} },
     computed: { userCount() {...} },
     mounted() { this.fetchUsers(); }
   }
   

2. 逻辑复用困难：mixins导致命名冲突、来源不明、隐式依赖
3. 类型推导差：this上下文复杂，TypeScript支持有限
4. 大型组件膨胀：一个组件几百行，功能混杂

Composition API优势

1. 按功能组织代码：同一逻辑聚在一起

   function useUserList() {
     const users = ref([]);
     const loading = ref(false);
     async function fetchUsers() { ... }
     onMounted(fetchUsers);
     return { users, loading, fetchUsers };
   }
   

2. 完美逻辑复用：自定义Hook（Composables）代替mixins
3. 更好的TypeScript支持：类型自动推断，无需this
4. 更小的Tree Shaking：导入的API才打包，没用到的Options API不会被树摇
5. 灵活的组织：可嵌套组合，像React Hooks一样自由

Composition API使用场景

场景	推荐
新项目	Composition API
简单展示组件	Options API可继续使用
复杂业务组件	Composition API
跨页面逻辑复用	Composables
大型团队协作	Composition API
已有Vue2项目迁移	渐进式使用

选择建议：

• Composition API不是替代Options API，而是补充
• 同一组件可混合使用两者（不推荐混合）
• <script setup>是Composition API的语法糖，更简洁
• 对于非常简单（无逻辑复用需求）的组件，Options API依然可接受

Vue官方推荐：

• 新项目使用Composition API + <script setup>
• 逻辑复用场景优先使用Composables而非mixins
• 保持团队一致性，不要混用风格