vue3为什么放弃vue2中的全局事件总线

Vue 3 弃用 Vue 2 中的全局事件总线（通常通过在 Vue 原型上挂载一个新的 Vue 实例实现，比如 this.$eventBus 或 Vue.prototype.$bus 的方式），主要是因为它与 Vue 3 的设计理念和核心优势（如更好的 TypeScript 支持、更清晰的代码结构、更强的可维护性）存在冲突。

1. ​隐式依赖与代码追踪困难：​​

   • 当一个组件使用 $bus.$emit 或 $bus.$on 时，事件的发射方和接收方之间没有明确的、在组件层次结构上的直接联系。
   • 难以追踪事件流：调试或理解代码时，很难确定哪个组件发出了某个事件，又有哪些组件监听并响应了这个事件。
   • 组件间形成隐式耦合：组件的功能依赖于外部（即事件总线）的状态或行为，破坏了组件的封装性，使得组件更难以单独理解和复用。

2. ​破坏类型推断（TypeScript 支持）：​​

   • 事件总线本质上是动态的：事件名称 (eventName) 是字符串，传递给 $emit 或接收自 $on 的 payload 可以是任何类型。这种灵活性使得静态类型检查（如 TypeScript）几乎无法对其进行有效验证。
   • 无法定义强类型的事件签名：在 TypeScript 项目中，你不能像定义组件 props 或 emits 那样，为全局事件总线上的事件定义清晰、强制的参数类型和结构，丧失了 Vue 3 对 TypeScript 的强力支持带来的开发体验和安全性优势。
   • 编辑器（如 VSCode）的智能提示（IntelliSense）也难以发挥作用。

3. ​事件名称冲突：​​

   • 在大型应用中，不同的团队或模块可能在不经意间使用相同的事件名称。由于全局总线只有一个，监听同名事件的组件会收到所有同名的消息，即使是来自无关来源的，这可能导致意外的行为和难以诊断的 bug。

4. ​内存泄漏风险：​​

   • Vue 2 的 $on 监听器需要手动移除（$off）。如果在组件销毁前忘记移除监听器（例如在 beforeDestroy 或 destroyed 钩子中），该监听器的回调函数会继续存在于内存中（因为事件总线实例是全局的，不会销毁），导致关联的组件实例也无法被垃圾回收，从而造成内存泄漏。

5. ​架构模式演进（Composition API）：​​

   • Vue 3 推崇的 ​Composition API​ 鼓励更灵活、可复用的逻辑组织方式，以及更显式的状态管理和组件通信。
   • 相比于通过事件总线在组件间“传话”，Composition API 更倾向于：
     • ​Props / Emits (v-model)：​​ 父-子组件通信的标准方式。
     • ​Provide / Inject：​​ 跨层级（祖先后代）组件通信。可以通过提供响应式对象或方法，在祖先组件中修改数据，后代组件就能响应更新。
     • ​状态管理库 (Pinia)：​​ 管理需要被多个不相干组件共享的全局状态。
   • 这些内置或推荐的方式提供了更清晰、更可预测、且类型更安全的通信机制，与 Vue 3 的设计哲学更吻合。

6. ​Tree-shaking 友好性：​​

   • 全局事件总线功能属于 Vue 核心的一部分（在 Vue 2 中）。无论你的组件是否使用它，这部分代码最终都会被打包进你的生产构建中。
   • Vue 3 的核心设计目标之一是更好的Tree-shaking 支持。所有非核心功能都迁移到了可选的库中（如 v-model 的参数、.sync 的替代等）。将事件总线移除核心层，符合按需引入（build smaller bundles）的理念。即使是使用第三方事件库（如 mitt），它们通常也非常轻量且 Tree-shaking 友好。