Vue2 的 Options API
在 Vue 2 中我们是如何组织代码的？ 我们会在一个 vue 文件中 methods，computed，watch，data中等等定义属性和方法，共同处理页面逻辑，我们称这种方式为 Options API。
Options 的缺陷 - 反复横跳
一个功能往往需要在不同的 vue 配置项中定义属性和方法，比较分散，需求简单还好，清晰明了；但是需求复杂之后，就会多出watch，computed，inject，provide等配置，这个 .vue 文件也会逐渐增大，且一个 methods 中可能包含 10-20 个方法，你往往分不清哪个方法对应着哪个功能。
当维护过超过200行的 .vue 组件，新增或者修改一个需求，就需要分别在data，methods，computed里修改 ，滚动条反复上下移动，我称之为『反复横跳』 比如我们加个累加器的需求，这种写代码上下反复横条的感觉， 相信大家都懂的。
Option的缺陷：mixin 和 this
反复横跳的本质，在于功能的分块组织，以及代码量太大了，如果我们能把代码控制在一屏，自然就解决了，vue2 里的解决方案，是使用 mixin 来混合，比如我们抽离一个 counter.js。
这样确实拆分了代码，但是有一个贼严重的问题，就是不打开 counter.js，App.vue 里的 this上，count，add这些属性，是完全不知道从哪来的，你不知道是mixin，还是全局install，还是Vue.prototype.count设置的，数据来源完全模糊，调试爽死你，这也是 option 的一个大问题，this是个黑盒，template 里写的 count 和 double，完全不知道从哪来的。
同时还会有 mixin 命名冲突的问题。
Vue3 中的 Composition API ( 组合式API )
Vue3 中的 Composition API 就是用来解决这个问题的：通过组合的方式，把零散在各个data，methods的代码，重新组合，一个功能的代码都放在一起维护，并且这些代码可以单独拆分成函数 。
在 Vue3 Composition API 中，我们的组件代码根据逻辑功能来组织的，一个功能所定义的所有 API 会放在一起（更加的高内聚，低耦合）。这样做即使项目很大，功能很多，我们都能快速的定位到这个功能所用到的所有 API，而不像 Vue2 Options API 中一个功能所用到的 API 都是分散的，需要改动功能，到处找 API 的过程是很费劲的。
因此，也就有了以下这张经典示例图：
