CustomEvent 不生效是因为默认不冒泡、不穿透 Shadow DOM，且事件目标需为同一节点；应改用编辑器实例持有的 EventTarget 作为事件中心，避免内存泄漏。

为什么直接用 CustomEvent 发事件不生效？ 常见现象是：在编辑器内部调用 dispatchEvent(new CustomEvent('editor:change', { detail }))，但外部监听不到。根本原因在于事件默认不冒泡、不穿透 Shadow DOM（如果编辑器用了 Web Components）、且事件目标必须是同一个 DOM 节点或其祖先——而编辑器封装后，外部代码往往没拿到那个节点实例。

• 编辑器若基于 contenteditable 或 iframe，事件目标可能是 div#editor 或 iframe.contentDocument.body，必须明确指定该节点为 dispatch 目标
• 若编辑器使用 Shadow DOM，需显式设置 bubbles: true 和 composed: true，否则事件出不了影子边界
• 不要用 window 或 document 作为事件总线——它们不是单例通信通道，而是全局事件流，易受干扰且无法隔离编辑器上下文

怎样让 CustomEvent 真正变成“全局总线”？ 核心思路：不依赖 DOM 传播路径，改用一个轻量的、可复用的事件中心对象，由编辑器实例主动持有并暴露给外部。

• 在编辑器初始化时创建一个私有事件中心：const eventBus = new EventTarget()
• 编辑器内部状态变更时，统一调用 eventBus.dispatchEvent(new CustomEvent('state:update', { detail: { type: 'selection', value: range } }))
• 外部订阅只需：editorInstance.eventBus.addEventListener('state:update', handler)（前提是编辑器把 eventBus 挂在实例上）
• 避免用 document.addEventListener 监听自定义事件——它只能捕获在 document 上派发的事件，和编辑器内部逻辑解耦困难

EventTarget 比 new EventEmitter() 更合适吗？ 是的，尤其在浏览器环境。现代 EventTarget 已原生支持：

• 同步触发，无异步调度开销，适合高频状态同步（如光标移动、输入中实时校验）
• 天然兼容 addEventListener/removeEventListener，无需额外学习 API
• 可与 AbortSignal 配合实现自动清理：editor.eventBus.addEventListener('state:update', handler, { signal: abortController.signal })
• 注意：IE 不支持，若需兼容，可用 event-target-shim，但不要自己手写 on/emit——容易漏掉事件移除、this 绑定、once 语义等细节

状态变更事件该携带什么数据？ 别传整个编辑器实例或 DOM 节点，只传可序列化、可比对、可测试的最小结构。

• 推荐结构：{ type: 'content', value: '<p>hello</p>', timestamp: Date.now() }
• 必须包含 type 字段，方便外部做 switch 分发；避免用单一事件名配不同 detail 结构
• 避免传 Range、Selection 对象——它们不能被克隆，跨 iframe 或调试时会报 InvalidStateError
• 如需还原选区，应转成可重建的描述：{ anchorOffset: 5, focusOffset: 12, anchorNodePath: [0,1,0] }

实际使用中，最易被忽略的是事件清理时机：编辑器销毁时，eventBus 上的监听器不会自动清除，若外部未手动 removeEventListener 或用 signal 控制，会造成内存泄漏——尤其在 React/Vue 动态挂载编辑器时。