Mitt 的本质是将散落的点对点通信收束为可管理的广播通道，适用于事件驱动、发布订阅无关联、数据一次性使用的场景；需确保单例唯一、语义化命名、监听配销毁，并可通过封装和分总线提升可靠性。
组件间通信太多导致逻辑混乱，本质是通信路径没收敛、责任边界不清晰。Mitt 的价值不是增加通信方式，而是把散落的“点对点喊话”收束成一条可管理、可追溯、低耦合的“广播通道”。它不解决所有通信问题，但特别适合那些不需要持久状态、只关心“发生了什么”的场景，比如通知、日志上报、临时状态同步、跨层级 UI 响应等。
什么时候该用 Mitt？先看三个典型信号
别一上来就引入总线。以下情况才真正适合 Mitt：
- 事件驱动明显：比如用户操作后要同时刷新列表、更新顶部计数、触发埋点——这不是状态同步，而是“一件事引发多个反应”
- 发布者和订阅者无直接关系：兄弟组件、深层嵌套组件、甚至独立模块（如工具类、SDK）需要响应 UI 变化，又不想层层透传 props
- 数据只用一次或生命周期短：Toast 提示、表单校验失败弹窗、快捷键全局响应——这类信息不需要进 store，也不该长期驻留内存
正确创建和使用事件总线的三步关键
很多混乱其实源于总线用法不规范。核心就三点：
-
单例唯一：在
src/utils/eventBus.js中统一创建并导出一个实例，所有地方 import 的都是同一个对象。重复调用mitt()会生成多个互不通信的总线，这是常见错误 -
语义化命名事件：用冒号分隔作用域和动作，例如
'user:logout'、'chart:export:success'。避免笼统的'update'或'data'，方便排查和类型推导 -
监听必须配销毁：在
onMounted中on，在onBeforeUnmount或onScopeDispose中off。尤其注意：传给off的回调函数必须是同一个引用，不能是内联函数
让 Mitt 更安全、更易维护的两个实践
基础用法容易，但项目变大后容易失控。加两层封装就能显著提升可靠性：
-
封装 emit 辅助函数：在总线文件里导出带类型检查的发送方法，比如
notifyError(msg)或emitUserLogin(user)。既约束参数结构，也集中管理事件名拼写 -
按功能拆分总线（可选）：大型项目可设多个总线实例，如
uiBus（Toast、Loading）、dataBus（列表刷新、缓存更新）。比混用一个总线更容易定位问题，也便于未来迁移
不复杂但容易忽略：Mitt 不是万能胶，它补的是 Vue3 通信模型里的缝隙。用对了，代码会更松、更专、更易测；用错了，只是把混乱从 props 搬到了 event 名里。
