现在开发Vue项目选Composition API还是Options API？Vue3到底该不该全用组合式？

terry 50分钟前阅读数 10 #Vue

回忆下这俩API的“出身”

要聊怎么选，得先搞清楚它们为什么会同时存在Vue3里，Options API是Vue2就有的那套“固定抽屉式”写法：data存数据，methods放方法，computed算衍生值，watch监听变化，还有mounted这些生命周期钩子，每个功能都塞在对应的“抽屉”里，分类清晰，新手拿到一个小项目代码，扫一眼每个抽屉就大概知道做了啥，但抽屉多了也麻烦，比如你做一个电商的商品详情页，收藏、加购、滚动显示顶部导航栏、获取商品规格，这四个功能的data、methods、computed全分散在四个不同的大区域，要改收藏功能，得上下来回跳着找代码,规模稍微大一点就像在找乱掉的拼图块。

Composition API的出现，就是为了补这个拼图块分散的坑，它的核心是把逻辑相关的代码“打包”在一起，不管是数据、方法、衍生值还是监听，都可以围绕一个功能模块写，比如刚才的收藏功能，可以单独抽成一个useCollect函数，加购抽useAddCart，滚动抽useScrollTop，商品规格抽useProductSpec，最后在setup函数（或者后来的script setup语法糖里）直接调用这些函数，把需要的变量方法return出来（或者直接暴露）给模板用，而且Composition API天生支持tree-shaking，没用到的功能代码比如watchEffect如果没写，打包的时候就会被自动删掉，Vue2的Options API不管你用不用，框架都会把那些空抽屉的结构塞进去，虽然体积差不大，但聊胜于无,对追求极致性能的大项目还是有用的。

别听“全用Composition才是正确姿势”的极端话：分场景才是明智选择

现在网上很多教程一上来就说“Vue3必须用script setup，Options已经淘汰了”，这绝对是误导，Options API没有被淘汰，Vue官方也明确表示会长期维护它，这俩是互补的关系，不是替代,那具体怎么分场景呢？

纯展示型小项目，或者新手刚学Vue，直接选Options API

纯展示型小项目是什么？比如个人简历官网、公司企业官网首页、只有登录注册加两个静态列表页的轻量工具，这类项目逻辑非常简单，每个“抽屉”里的内容很少，上下跳找代码的概率几乎为零，这时候用Options API的“抽屉式”分类反而更直观，新手看了不用理解ref、reactive、toRefs这些概念，就能快速上手写东西，毕竟Options的逻辑太好懂了：先定义数据，再写修改数据的方法，最后挂钩子拿数据，完全符合人类从“准备材料”到“干活”再到“收尾”的思维顺序。

我之前带过几个刚毕业的前端实习生，一开始就让他们用Composition，结果光ref和reactive的区别、toRefs什么时候用就搞了一周，后来改成先学Options写小demo，比如Todo List初级版，只用data、methods、mounted，再慢慢加computed、watch，等掌握了Vue的核心响应式原理、组件通信这些东西，再过渡到Composition，上手速度快了三倍不止，而且写纯展示型小项目的时候，用Options写出来的代码行数甚至比script setup更少？比如一个简单的计数器，Options大概5行setup函数之前的代码（不算template），script setup要写ref、暴露变量（当然现在不用return了，但逻辑步骤还是一样），行数差不多，但看起来Options的结构更“板正”,小项目维护起来也完全没问题。

逻辑复用需求高、或者项目规模中等以上，必须用Composition API

逻辑复用是Composition API最大的亮点，没有之一，Vue2的时候逻辑复用靠什么？靠mixin对吧？但mixin的问题太多了：首先是命名冲突，比如两个mixin都有一个叫做loading的data，用的时候会互相覆盖，而且找问题的时候根本不知道是哪个mixin搞的；然后是来源不透明，用了多个mixin之后，模板里的变量和方法根本不知道是从哪来的，得打开每个mixin文件一个一个找；最后是可维护性差，一旦改了mixin里的某个功能，所有用到这个mixin的组件都要跟着测试,牵一发而动全身。

Composition API的组合式函数（也就是开头提到的useCollect、useAddCart这些）完美解决了mixin的所有问题：命名冲突？可以在组合式函数里定义局部变量，最后只暴露需要给父组件的，而且暴露的时候还可以重命名；来源不透明？你在组件里调用useCollect，那所有从这里出来的变量和方法，都是和收藏功能相关的，一眼就能看明白；可维护性差？组合式函数是独立的文件，你改了收藏功能的逻辑，只需要测试用了useCollect的组件，而且可以用测试框架单独测试组合式函数，不用挂载组件就能测逻辑,效率高多了。

比如我之前做的一个教育类直播系统，里面有十多个组件都用到了“用户权限验证”、“实时消息监听”、“倒计时功能”这三个功能，要是用Vue2的mixin，至少要写三个mixin文件，每个文件大概100-200行代码，然后每个组件里都要import这三个mixin，改的时候提心吊胆，生怕覆盖了其他组件的变量，后来用Composition API重构，把这三个功能分别抽成useAuthCheck、useLiveMessage、useCountDown三个组合式函数，每个函数100行左右，逻辑清晰，注释完整，用的时候只需要在组件里调用，比如倒计时组件，直接写const { count, startCount, pauseCount, resetCount } = useCountDown(1800)，然后模板里用count就行，要是需要改倒计时的逻辑，比如把倒计时暂停的逻辑改成暂停后自动续5秒，只需要改useCountDown这个文件，其他用到的组件根本不用动，测试的时候也只需要写一个针对useCountDown的单元测试，不用管组件的UI,太爽了。

除了逻辑复用，项目规模中等以上的时候，Composition API的“逻辑打包”优势也非常明显，比如刚才说的教育类直播系统的直播间组件，大概有3000行逻辑代码，要是用Options API，data、methods、computed、watch、mounted这些区域各占几百行，上下跳找代码真的会疯掉，用Composition API重构之后，把直播间的逻辑分成了“视频播放控制”、“弹幕发送和展示”、“礼物打赏和弹窗”、“连麦申请和处理”、“直播间状态管理”这五个大的组合式函数，每个组合式函数大概600行，最后在script setup里按顺序调用，每个组合式函数的代码都是独立的，改视频播放就看useVideoControl，改弹幕就看useDanmaku，完全不用管其他部分,维护效率提升了至少五倍。

两种API混用行不行？当然行！官方都推荐这种“渐进式”用法

刚才说的两种场景都是极端情况，大部分项目其实是介于两者之间的：有几个纯展示型的小组件，也有几个逻辑复杂、需要复用的大组件，这时候完全可以两种API混用，官方也明确支持这种做法,而且还给了具体的混用规则。

具体怎么混用呢？比如你已经有一个用Options API写的Vue2项目，现在要升级到Vue3，或者要在这个项目里加一个新的逻辑复杂的组件，这时候可以直接在Vue3项目里用Options API写旧组件，用Composition API写新组件，完全兼容，或者你有一个用Composition API写的大组件，里面有一个小的纯展示型的子组件，这时候子组件完全可以用Options API写，不用强制用script setup。

还有一种情况，就是你用Composition API写了一个大组件，但里面有几个生命周期钩子的逻辑非常简单，比如mounted的时候只需要拿一个静态的配置文件，这时候可以在script setup里直接用onMounted，也可以在Options API的mounted里写（不过既然用了script setup，还是尽量用onMounted更统一），Vue3还支持在Composition API里访问Options API的属性，比如this.$store、this.$router，不过现在官方推荐用pinia代替vuex，用useRouter和useRoute代替this.$router和this.$route，所以尽量还是用Composition API风格的API。

除了场景，还要看团队习惯和技术债务：别为了用而用

刚才聊的都是技术层面的选择，实际开发中还要考虑非技术层面的因素，比如团队习惯和技术债务，如果你的团队里大部分人都是从Vue2转过来的，对Options API非常熟悉，对Composition API一知半解，这时候不要强制全团队转Composition，可以先让一两个技术骨干用Composition写一些核心的、逻辑复杂的组件，然后慢慢推广，让团队成员有一个适应的过程，如果强制全转，可能会导致开发效率下降，甚至出现大量的bug,得不偿失。

还有技术债务的问题，比如你有一个已经上线了两三年的Vue2项目，代码量很大，有几十上百个组件，这时候不要为了用Vue3的Composition API就把所有组件都重构一遍，重构的成本太高了，而且可能会引入新的bug，这时候可以只升级Vue3的核心版本，用Vue2的兼容模式（也就是Vue 3 Migration Build），然后逐步重构一些逻辑复杂、维护成本高的组件，其他纯展示型的组件继续用Options API就行,等有时间有精力了再慢慢全部重构。