组合式 (Composition) API 的一大特点是“非常灵活”，但也因为非常灵活，每个开发都有自己的想法。加上项目的持续迭代导致我们的代码变得愈发混乱，最终到达无法维护的地步。本文是我这几年使用组合式API的一些经验总结，希望通过本文让你也能够写出易维护、优雅的组合式API代码。
vue2的选项式API因为每个选项都有固定的书写位置（比如数据就放在data里面，方法就放在methods里面），所以我们只需要将代码放到对应的选项中就行了。
优点是因为已经固定了每个代码的书写位置，所有人写出来的代码风格都差不多。
缺点是当单个组件的逻辑复杂到一定程度时，代码就会显得特别笨重，非常不灵活。
vue3推出了组合式 (Composition) API，他的主要特点就是非常灵活。解决了选项式API不够灵活的问题。但是灵活也是一把双刃剑，因为每个开发的编码水平不同。所以就出现了有的人使用组合式 (Composition) API写出来的代码非常漂亮和易维护，有的人写的代码确实很混乱和难易维护。
比如一个组件开始的时候还是规规矩矩的写，所有的ref响应式变量放在一块，所有的方法放在一块，所有的computed计算属性放在一块。
但是随着项目的不断迭代 ，或者干脆是换了一个人来维护。这时的代码可能就不是最开始那样清晰了，比如新加的代码不管是ref、computed 还是方法都放到一起去了。如下图：
只有count1和count2时，代码看着还挺整齐的。但是随着count3的代码加入后看着就比较凌乱了，后续如果再加count4的代码就会更加乱了。
为了解决上面的问题，所以我们约定了一个代码规范。同一种API的代码全部写在一个地方，比如所有的 props 放在一块、所有的 emits 放在一块、所有的 computed放在一块。并且这些模块的代码都按照约定的顺序去写，如下图：
随着vue组件的代码增加，上面的方案又有新的问题了。
还是前面的那个例子比如有5个count的ref变量，对应的computed和methods也有5个。此时我们的vue组件代码量就很多了，比如此时我想看看computed1和increment1的逻辑是怎么样的。
因为 computed1和increment1 函数分别在文件的computed和methods的代码块处，computed1 和increment1之间隔了几十行代码，看完computed1的代码再跳转去看increment1的代码就很痛苦。如下图：
