发布订阅不能替代状态管理，因其不保存状态、仅中转消息；同步状态需依赖唯一响应式数据源（如 reactive/ref），发布订阅仅作变更通知。
Vue 中处理组件间同步状态，发布订阅不是替代状态管理的方案，而是补充通信手段 —— 它不管理状态本身，只负责“通知变化”。真正要同步状态，核心仍是响应式数据源；发布订阅只是让多个组件能及时感知并响应这个变化。
为什么发布订阅不能代替状态管理
发布订阅机制本身不保存状态，它只做一件事：消息中转。比如 A 组件 emit('user-updated', { name: 'Alice' })，B 和 C 组件 on('user-updated', handler) 听到了，但它们各自怎么更新自己的 user 数据，得靠自己决定。如果每个组件都维护一份副本，就容易出现状态不一致。
真正需要同步时，必须有一个唯一可信的数据源（例如一个 ref 或 store），所有组件读取和修改都通过它。发布订阅只是触发“刷新”或“拉取”的信号，而不是搬运状态。
推荐组合：响应式 store + 发布订阅触发更新
在 Vue3 中，更合理的方式是：
vue-admin-change-reviewer
下载
审查 Vue 管理后台的变更请求（Vue 2 + Element UI，Vue 3 + Element Plus）。重点关注最小化变更实现、上线风险检查以及回归检查清单生成。
立即学习“前端免费学习笔记（深入）”；
- 用 reactive 或 ref 创建一个共享状态对象（如
const userStore = reactive({ name: '', avatar: '' })） - 各组件直接使用该 store（无需 props 传递），视图自动响应
- 当某处逻辑需要“广播变更”（比如用户退出登录后清空多个模块缓存），再用 eventBus.emit('auth-change', 'logged-out')
- 其他模块监听该事件，执行清理、重置等副作用操作，但不改动 userStore 本身——状态仍由 store 统一控制
避免常见陷阱：内存泄漏与重复订阅
使用自定义 eventBus（如 Class 实现的 EventBus）时，必须注意生命周期：
- 在 onMounted 中订阅，在 onBeforeUnmount 中调用 off 清理
- 不要在 setup() 顶层多次调用 on()，否则每次组件重建都会新增监听器
- 若使用 once，确保逻辑确实只需执行一次；否则应显式 off，尤其在 watch 或异步回调中注册的监听
- 不建议在 computed 或渲染函数中动态订阅——它们可能高频触发，导致监听器爆炸
什么场景更适合用发布订阅而非 Vuex/Pinia
当你只需要轻量、临时、事件驱动的协作，而不是持久化状态管理时：
- 全局快捷键响应（如 Ctrl+S 触发保存，多个编辑区都要监听）
- 模态框关闭后通知父级刷新列表（不涉及数据存储，只是一次性通知）
- 第三方 SDK 加载完成，广播给所有等待它的组件
- 微前端子应用间低耦合通信（彼此无依赖，只靠约定 topic）
这类需求不需要状态回溯、时间旅行调试或严格的状态变更流程，发布订阅足够清晰高效。
