JavaScript 发布订阅模式
✏️ 可编辑
加载编辑器...
实时预览
⌘+Enter 运行⌘+R 重置
关于此练习
发布订阅（Pub/Sub）可以理解成“广播站”：
- 发布者（publish）只负责发消息
- 订阅者（subscribe）决定要不要听这条消息
发布者不需要知道谁在听，这就是“解耦”。
中级⏱ 25-30 min
学习目标
- 理解发布者与订阅者角色分离
- 掌握最小事件总线 API（on/emit）
- 支持多订阅者与 payload 透传
场景说明
你在做学习消息中心：
一个模块发出“任务完成”事件，多个模块（通知、积分、日志）都要响应。
为什么这么做
- 前端 JS 不是“会写语法”就够，重点是能稳定地改 DOM 和处理交互状态。
- 先拆事件流（触发 -> 处理 -> 更新 UI），再写代码，错误率会明显下降。
- 通过规则验证能帮助你建立“可测试”的前端思维。
动手练习
- 先用注释写出事件流，再实现函数。
- 补一个“异常输入”或“空数据”分支。
- 解释每条验证规则为什么需要。
常见误区
- 只关注功能跑通，不验证边界输入和重复点击场景。
- 事件绑定和状态更新写在一起，后续难维护。
- console 看起来对，但 UI 没有真实更新。
本节交付物
一份可复用的交互组件脚手架（事件流说明 + 关键函数 + 边界处理）。
我的进度
完成步骤0 / 3
总尝试次数0
最佳分数0%
达标标准（可勾选）
完成当前 Lab 前建议确认
反思题（建议完成）
请用 2-3 句话说明本 Lab 的事件流（触发 -> 处理 -> 更新）。
你补了哪个边界场景？为什么这个场景容易漏？
你现在对这个交互模式的掌握程度？
标签
JavaScriptArchitecturePubSubEvent Bus