JavaScript观察者模式本质是函数回调的组织方式，核心为on/emit/off三行为；手写事件总线50行内可实现，无需EventTarget，更轻量可控。
JavaScript 观察者模式不是“必须用类实现的高级设计模式”，它本质是函数回调的组织方式；自定义事件系统也不需要依赖 EventTarget 才算“正规”——手写一个轻量、可控、无依赖的事件总线，50 行内就能搞定。
什么是观察者模式在 JS 中的真实形态
它就是：一个对象维护一堆函数（订阅者），当某个状态变化或动作发生时，挨个调用这些函数。没有强制的类结构，也不需要“主题/被观察者”这种术语包装——on、emit、off 这三个行为就已覆盖全部语义。
常见错误是把观察者和发布-订阅混为一谈，或强行套用 Java/C# 的接口抽象。JS 里更自然的做法是：用对象存函数数组，用字符串作事件名索引，用闭包隔离作用域。
- 事件名是任意字符串，包括
"user:login"、"data:update"，支持冒号分隔语义层级 - 每个事件可绑定多个监听器，执行顺序 = 绑定顺序（FIFO）
- 监听器函数接收参数由
emit调用时传入，不限类型、不限数量
手写一个最小可用的事件总线（无依赖）
下面这个 EventBus 类只做三件事：注册、触发、移除。不处理异步、不支持通配符、不自动清理内存——正因如此，它才足够透明、可调试、易修改。
立即学习“Java免费学习笔记（深入）”；
class EventBus {
constructor() {
this.events = {};
}
on(type, fn) {
if (!this.events[type]) this.events[type] = [];
this.events[type].push(fn);
}
emit(type, ...args) {
const fns = this.events[type] || [];
fns.forEach(fn => fn(...args));
}
off(type, fn) {
if (!this.events[type]) return;
this.events[type] = this.events[type].filter(f => f !== fn);
}
}使用示例：
const bus = new EventBus();
bus.on('api:success', (data) => console.log('got', data));
bus.emit('api:success', { id: 123 }); // 输出 "got { id: 123 }"-
on不校验重复函数，若需去重，自己加!fns.includes(fn) -
off移除时必须传入**同一个函数引用**，匿名函数无法被清除 - 若要支持一次性的监听器（
once），只需在on内部包装一层自动off的函数
为什么不用原生 EventTarget？什么场景下它反而更麻烦
EventTarget 是浏览器环境的标准 API，但它的设计面向 DOM 事件流（捕获/冒泡/取消），对纯逻辑通信属于过度工程：
- 必须用
CustomEvent包装数据，多一层序列化开销（哪怕只是new CustomEvent('x', { detail: obj })） - 不支持直接传参，所有数据得塞进
detail字段，取用时总要写e.detail.xxx - 事件名必须是字符串，但
dispatchEvent不接受额外参数，想传多个值只能靠detail打包 - Node.js 环境默认不提供
EventTarget（v14.5+ 才有），兼容性需额外判断
除非你在写 Web Component 或需要与 DOM 事件互通，否则手写事件总线更直觉、更可控。
容易被忽略的内存泄漏点
最常出问题的不是代码写错，而是忘了清理：
- 组件销毁（如 React
useEffect清理、VuebeforeUnmount）时，必须调用off，否则监听函数长期持有外部作用域引用 - 用箭头函数注册监听器 → 无法被
off移除 → 每次渲染都新增监听器 → 内存持续增长 - 全局总线（如单例
bus）上绑定的函数，若来自某模块内部，该模块被热更新或卸载后，监听器仍驻留内存
解决思路很简单：把监听器声明为模块级常量，或在注册时返回取消函数（类似 addEventListener 的 remove），而不是依赖后期手动匹配移除。
