customelement需主动集成eventtarget实现私有事件总线。直接用document.dispatchevent易致命名冲突、作用域失控和内存泄漏；而每个实例独享eventbus可精准通信、同步触发且支持abortsignal自动清理。
CustomElement 本身不内置事件总线，但你可以用它配合 EventTarget 实现轻量、解耦的状态通信。关键不是“HTML自定义元素自带总线”，而是你得主动把总线塞进组件里——否则所有监听都依赖 DOM 冒泡或全局 document，容易失控。
为什么不能直接用 document.dispatchEvent 做总线？
常见错误是：在自定义元素里调用 document.dispatchEvent(new CustomEvent('foo'))，然后在别处用 document.addEventListener('foo') 监听。这看似可行，但实际埋了三个坑：
- 事件污染全局命名空间，多个组件用同名事件（比如
'select'）会互相干扰 - 无法精准控制作用域——你发的事件可能被完全无关的模块捕获
- 卸载组件时容易漏掉
removeEventListener，导致内存泄漏
怎么给 CustomElement 配一个私有 EventTarget 总线？
在自定义元素的 constructor 或 connectedCallback 中初始化一个独立的 EventTarget 实例，并暴露为属性：
class MyEditor extends HTMLElement {
constructor() {
super();
this.eventBus = new EventTarget(); // ← 关键：每个实例独享
}
updateSelection(range) {
this.eventBus.dispatchEvent(
new CustomEvent('selection:change', { detail: { range } })
);
}
}
外部订阅时直接操作该实例：
const editor = document.querySelector('my-editor');
editor.eventBus.addEventListener('selection:change', e => {
console.log(e.detail.range);
});
// 清理也简单：
// editor.eventBus.removeEventListener('selection:change', handler);
EventTarget 比手写 EventBus 更适合 CustomElement 吗？
是的，尤其在浏览器环境。原因很实在：
-
EventTarget是原生 API，同步触发，没有额外调度开销，适合高频状态（如输入、光标移动） - 天然支持
addEventListener/removeEventListener，和现有习惯一致，不用学新 API - 可直接配合
AbortSignal自动清理：editor.eventBus.addEventListener('state:update', handler, { signal }) - IE 不支持？加个
event-target-shim就行，比自己实现on/emit安全得多——手写容易漏掉this绑定、重复注册、once语义等细节
CustomElement 中 dispatchEvent 的路径选择
自定义元素内部发事件，有三种常见方式，适用场景不同：
-
this.dispatchEvent()：用于向父级 DOM 树冒泡，适合“我完成了某事，请上层处理”（如<my-input></my-input>触发'input'） -
this.eventBus.dispatchEvent()：用于内部状态通知，不走 DOM，仅限本实例及明确订阅者 -
document.dispatchEvent()：仅当真需要跨根节点、跨 Shadow DOM 且无其他桥梁时才用，应加命名空间前缀（如'myapp:save'）避免冲突
多数时候，this.eventBus 是最可控的选择；混用三者时，务必在文档里写清每种事件的流向和生命周期责任。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
