本文转载自微信公众号《微信大学前端技术》，作者黄勤。转载本文请联系微一大学前端技术公众号。前言，秦胖第三篇来袭！最近在计划中列了一个vue3的清单。关于vue3，虽然很久以前看过，只是写了几个小demo，简单了解一下，而且我们公司的主要技术栈也是vue。最近趁着这个学习的势头，赶紧申请了一个内部项目，想用vue3来实践一下。希望这篇总结能给一些小伙伴提供一些帮助。下面主要从两部分进行总结，一部分是可能混淆的点或者一些常见的问题，另一部分是实践过程中遇到的陷阱/注意点。关于vue3的一些问题1：使用Vue3时，必须要用CompositionAPI的形式来写页面吗？答案是不。需要注意的一点是：Vue3并没有放弃OptionsAPI，甚至会全面支持兼容Vue2语法的工作。CompositionAPI的后台主要是解决逻辑抽象和复用的问题，但不代表它已经成为Vue3的标准。所以，如何区分使用OptionsAPI还是CompositionAPI，主要看业务逻辑复杂的程序，比如一些简单的toast/button等基础组件，使用optionsAPI会更清晰简洁。对于比较复杂的业务逻辑，可以使用CompositionAPI，将单块逻辑拆分成一个模块，通过hook函数解决。2：在Vue3中混用OptionsAPI和CompositionAPI会影响性能吗？不会，其实从问题1可以很清楚的看出，不会对性能有什么影响。思维不要被optionapi限制，更要注意逻辑的衔接。问题三：关于setup中没有this的问题。vue官方文档是这样解释的：在setup()中，this不会是对活动实例的引用，因为setup()在其他组件选项解析之前被调用，所以setup()中的this与其他选项中的this行为完全不同.在将setup()与其他选项API一起使用时，这可能会导致混淆。这意味着，除了props之外，您将无法访问组件中声明的任何属性——本地状态、计算属性/方法。但是从源码实现中，你会发现组件实例其实是先创建的，而函数之所以不能访问this，是因为它在执行setup函数的时候没有将组件实例实例传给setup。它也不将this指向实例实例。所以执行顺序实际上是：组件实例是在setup函数执行之前创建的，但是执行setup时，组件还没有挂载，而且是晚于beforeCreatehook，早于createhook。4：reactiveVSref当你第一次阅读文档时，人们经常会比较这两者。总结一下：反应式API：可以将对象数据变成响应式数据（相当于2.x中的Vue.observable()），CompositionAPI建议用户主动定义响应式数据，而不是内部黑盒处理ref：对于数组或者对象来说，本质是响应式的，读取值的时候就是ref.value。另外，注意toRefs：对于组合函数返回，在响应对象时使用toRefs，本质上帮助我们做了一层getter和setter处理，解构得到响应数据，也减轻了ref5的一些心理负担：Vue3responsive比Vue2性能更好吗？vue3出来的时候经常听到一些回答说vue3的性能比vue2好，但是真的是这样吗？在Vue3发布的那段时间（我也去1元的源码上课分析学习了很多：老黄YYDS），甚至群里的每个人都在讨论这个问题。首先在实现上：我们都知道vue2中的响应式主要是由于Object.defineProperty，它主要是劫持对象的属性，所以无法观察到对象属性的增删改查，而在vue中，它用Proxy实现，劫持的是整个对象，可以避免vue2留下的问题，但是也有一个明显的缺点就是兼容性不够强。但是和Vue2相比，需要知道的是，vue3的性能优势主要体现在初始化阶段。因为在Vue2中定位响应式对象的时候，会递归的把子对象变成响应式的。而Vue3其实是惰性执行：当真正访问到对象属性时，子对象的递归执行就变成响应式了。6：VueCompositionAPIVSReactHooksVue3的CompositionAPI在写法上和ReactHooks非常相似。每个人都忍不住将它们进行比较。关于这部分内容的PK，我们小伙伴已经总结过了。很全面，这里就不赘述了。传送门：VueCompositionAPI和ReactHooks对比：https://juejin.cn/post/6847902223918170126除了一些常见问题，更重要的是实践。对于新的项目，可以直接从vue3入手，但是更多的是对于已有的项目，从vue2升级到vue3的时候，肯定会踩很多坑。以下是您在实践中可能遇到的一些注意点和陷阱。报告以下警告：Informscriptsetup仍是一项实验性新功能，尚未作为官方功能发布。以后会不会有变化还不好说。[@vue/compiler-sfc]
