Vue3移除EventBus根本原因是与现代工程实践系统性冲突：类型安全弱、调试困难、隐式耦合、内存泄漏风险高，官方已废弃$on/$off；推荐用props/emit、provide/inject、模块化mitt或Pinia替代。

Vue 3 中不建议使用传统事件总线，根本原因不是“不能用”，而是它与现代 Vue 工程实践存在系统性冲突——类型安全弱、调试困难、耦合隐晦、维护成本高。官方已明确移除 $on/$off 等 API，不再支持基于 Vue 实例的全局总线。

类型推断彻底失效，TS 开发体验大打折扣

事件名是字符串，载荷（payload）结构完全动态，TypeScript 无法校验：

• 监听时传错字段名或类型，编译器不报错，运行时才崩溃
• IDE 无法自动提示事件名和参数结构，全靠人工记忆或翻文档
• 即使手动声明模块类型（declare module），也要为每个事件单独维护接口，项目越大越难同步

事件流向不可见，调试如同盲人摸象

一个 emitter.emit('data-updated') 可能被 5 个组件监听，但没有任何机制告诉你：

vue-component-analyzer

递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。

下载

• 谁注册了这个监听？在哪个生命周期注册？是否已销毁？
• 事件从哪个组件发出？触发条件是否合理？有没有重复 emit？
• 组件卸载后监听器未清理，回调函数持续持有组件引用，导致内存泄漏

隐式耦合破坏封装，重构风险陡增

组件看似独立，实则依赖一个全局“广播站”：

立即学习“前端免费学习笔记（深入）”；

• 两个本无关联的模块，因用了相同事件名（如 'close-modal'）而互相干扰
• 删除一个组件时，必须全局搜索所有 bus.on('xxx')，漏掉一处就埋下隐患
• 单元测试难以隔离：测试 A 组件时，B 组件的监听器可能意外触发副作用

有更优替代方案，且各司其职

Vue 3 提供了语义清晰、可追踪、可测试的通信路径：

• 父子通信：严格使用 props + defineEmits，类型安全、调用链明确
• 祖孙跨层：用 provide/inject 配合响应式对象，支持只读/只写约束
• 模块内广播：按业务域拆分 mitt 实例（如 userBus、cartBus），避免命名污染
• 全局状态：Pinia 管理共享状态，附带 devtools 时间旅行、状态快照、插件扩展能力