我用Vue3写了半年组合式API，谈谈它比类组件好在哪

从Vue 2的Options API一路写过来，去年在新项目里全面切换到Vue 3 + 组合式API。半年下来，最大的感受是：再也回不去了。不是Vue 2不好，而是组合式API解决了我在类组件时代反复遇到的几个“老毛病”，今天想聊聊这些真实的体感差异。

逻辑复用：从“混入噩梦”到“顺手拈来”

以前用类组件（或者Options API的mixin），最头疼的就是逻辑复用。抽一个mixin出来，看着是省了代码，但一旦多个mixin混在一起，你根本分不清某个data字段是哪个mixin注入的，连this上挂的东西都得靠开发者自觉命名前缀。更别说mixin之间的命名冲突，排查起来简直是精神折磨。

组合式API的useXxx函数把这个问题彻底解决了。每个hook就是一个独立的作用域，返回什么、内部状态怎么变化，一目了然。我在项目里写了一个useTableList处理分页和筛选，又一个usePermission控制按钮权限，组件里调用两个hook，各自返回各自的state和方法，谁也不会污染谁，代码评审的时候也轻松很多。

代码组织：按功能切分，而非按选项切分

类组件时代，写一个复杂页面，data里堆二十个字段，methods里挂三十个方法，computed里再塞七八个计算属性。表面上结构清晰——数据都在data里嘛。但实际开发中，你往往是在处理三个或四个独立的功能域，比如一个购物车页面，同时涉及商品列表、优惠券计算、结算金额、收货地址。这些功能的data、computed、methods是交织在一起的，你要改优惠券逻辑，得在data里找优惠券字段，去computed里找折扣计算，再去methods里找领券方法——跳来跳去，上下文反复切换。

用组合式API，我习惯把每个功能域直接写成一个独立的代码块，甚至抽成hook。比如结算金额相关的逻辑，从响应式数据到计算属性再到事件处理函数，全部挨在一起。改需求的时候，我只盯着文件里那一小段，脑子不用装整个组件的全貌，开发效率提升非常明显。

TypeScript支持：告别“我猜this是什么类型”

类组件用TypeScript，其实也能写，但总有那么点别扭。this的类型推导在mixin混入或者复杂继承关系下经常失效，你不得不写一堆类型断言或者接口补充说明。而在组合式API里，一切都是普通的函数调用和变量赋值，类型推导天然友好。useState返回的ref，类型清清楚楚，props用泛型定义，emit也用类型约束。写半年下来，基本没遇到过因为this指向问题引发的类型报错。

心智负担：从“约定大于实现”到“直接了当”

类组件有很多隐性的规则——生命周期要记名字、this指向要时刻留神、mixin的合并策略要背。这些约定在简单项目里还好，到了大型项目就成了团队的沟通成本。组合式API大幅削减了这种“魔法感”，它本质上就是函数，你在JavaScript里怎么组织函数，就可以怎么组织它。新人上手时不需要先背一套框架哲学，直接看代码调用关系就能理解意图。而且setup函数只执行一次，所有逻辑都是显式的，调试时看调用栈也直观得多。

写在最后

当然，我不是说类组件一无是处——它简洁、直观，适合快速原型。但当你面对的是一个需要长期迭代的中大型项目，组合式API在可维护性、类型安全和团队协作上的优势是实打实的。半年用下来最深的体会是：好的API设计不该让开发者去迁就框架的规则，而是顺着开发者天然的思维方式去组织代码。如果你还在观望，我的建议是：下一个新项目，大胆试一把。