前言
- 常网IT源码上线啦！
- 本篇录入吊打面试官专栏，希望能祝君拿下Offer一臂之力，各位看官感兴趣可移步🚶。
- 有人说面试造火箭，进去拧螺丝；其实个人觉得问的问题是项目中涉及的点 || 热门的技术栈都是很好的面试体验，不要是旁门左道冷门的知识，实际上并不会用到的。
- 接下来想分享一些自己在项目中遇到的技术选型以及问题场景。
我了解了这个世界，但依然热爱生活。
一、前言
Mixin 是一种常见的代码复用方式，广泛应用于将多个组件间的逻辑进行复用。
它类似于 React 中的高阶组件（HOC），通过将不同的逻辑片段（如数据、生命周期钩子、方法等）合并到一个对象中，增强组件的功能性。
为什么vue2很少有开发者使用mixin？
我们先了解一下内部原理。
二、分析
Mixin 通过策略模式来实现合并逻辑
- data 和 provide：后者的值会扩展前者的值，若属性名相同且值不是对象，后者的值会覆盖前者；如果值为对象，且不相等，则会继续合并。
- components, filters, directives：后者的组件、过滤器、指令会覆盖前者的属性。
- props, methods, inject, computed：会创建一个新的对象（例如
ret），遍历前者的属性或方法，扩展到ret中，接着遍历后者的属性或方法，后者的内容会覆盖前者。 - 默认策略：未定义的策略会默认采用前者的值，若后者有，则使用后者的值。
三、优点
虽然很少有人用，但事物都有两面性，再坏的人，也有优点，何况mixin。
它可以：
- 提高代码复用性：通过
Mixin可以将多个组件中的公共逻辑提取到一个地方，减少代码重复。 - 无需传递状态：不需要通过 props 或其他方式显式传递状态，代码更加简洁。
- 维护方便：共享逻辑集中在一个地方修改时，其他依赖该
Mixin的组件不需要做额外更改。
四、缺点
相信缺点，大家都知道。
- 命名冲突：当多个
Mixin中定义了相同的属性或方法时，容易出现命名冲突，导致无法预料的行为。 - 难以维护：如果滥用
Mixin，大量混合的逻辑可能导致代码复杂，后期难以维护和理解。 - 调试困难：由于数据和方法是合并在一起的，难以追踪某些值的来源，调试时可能会增加复杂度。
- 代码重复难以避免：在一些场景中，
Mixin会导致逻辑的过度复用，反而让代码更难理解和管理。
还有的就是无法直接访问组件的实例。
Mixin 无法直接访问组件的 this 实例（组件的属性和方法），特别是在 data 和 methods 中定义的属性和方法，是通过对象合并的方式引入的。
那有没有性能问题呢？
是有的。每次组件实例化时，Vue 都需要将 Mixin 中的属性和方法合并到组件实例中，可能导致一些性能开销。对于大量使用 Mixin 的组件，合并逻辑的计算可能会增加渲染时间，尤其是在组件的数量较多时。
这也是很多人不想用的原因。
vue也深知这个问题，所以在vue3提出了解决方案。
Composition API
Vue 3 引入的 Composition API 在一定程度上解决了 Mixin 的缺点，提供了一种更加灵活、可组合的方式来组织和复用组件的逻辑。与 Mixin 的方式不同，Composition API 通过将逻辑拆分成函数来避免命名冲突，并且使得代码的作用域更加明确，避免了不必要的全局状态依赖。
- 避免命名冲突：在
Composition API中，我们可以通过自定义命名和逻辑函数来避免命名冲突，而不是将多个属性或方法混合在同一个对象中。 - 代码更加可追溯：通过显式的函数调用和组合，代码的来源和执行流程更加清晰，调试时也更容易定位问题。
- 逻辑更具可重用性：可以将逻辑拆解成更小的函数，并根据需要灵活地在不同的组件中复用，避免了混合多个逻辑块的复杂性。
setup(){
const { love: love1 } = useLove(); // 显式使用
}
至此撒花~
后记
Mixin 虽然能带来代码复用的便利，但也带来了一些管理和维护上的挑战，特别是在复杂项目中。是吧
不加以谨慎使用，可能会导致代码难以理解和维护，调试困难，甚至引入一些潜在的错误。那就gg
Vue 3 的 Composition API）提供了更灵活、更清晰的逻辑复用方式。
我们在实际项目中或多或少遇到一些奇奇怪怪的问题。
自己也会对一些写法的思考，为什么不行🤔，又为什么行了？
最后，祝君能拿下满意的offer。
我是Dignity_呱，来交个朋友呀，有朋自远方来，不亦乐乎呀！深夜末班车
👍 如果对您有帮助，您的点赞是我前进的润滑剂。
