自定义事件不能替代原生事件流，仅作补充；其冒泡行为由构造时bubbles选项决定，addeventlistener第三参数仅控制监听时机；ie11需回退createevent；event.detail适合结构化数据但有序列化限制；stopimmediatepropagation会阻止同元素其余监听器执行；跨组件通信应选用document或custom element为事件目标。
自定义事件不能替代原生事件流，它只是补充；直接 dispatch 一个没声明过 bubbles 的 CustomEvent，在冒泡阶段会被静默丢弃。
为什么 addEventListener 第三个参数对自定义事件没用
因为 CustomEvent 构造时的 bubbles 和 cancelable 才决定事件能否冒泡或被阻止，addEventListener 的第三个参数（useCapture）只控制监听时机，不改变事件本身行为。
- 若构造时写
new CustomEvent('foo', { bubbles: false })，即使监听写el.addEventListener('foo', h, true)，也进不了捕获阶段——事件压根不参与事件流 - 若漏传
{ bubbles: true }，事件只在触发元素上触发，父级addEventListener完全收不到 - IE 11 及更早版本不支持
CustomEvent构造函数，需用document.createEvent('CustomEvent')+initCustomEvent()回退
data 属性传参比 event.detail 更灵活但有边界
用 dataset 存参数（如 data-id="123"）适合简单标识，而 event.detail 适合传递结构化数据（对象、数组），但要注意序列化成本和调试可见性。
-
dataset值始终是字符串，数字/布尔需手动转换：Number(el.dataset.id)、el.dataset.active === 'true' -
event.detail可直接传对象，但若对象含函数、DOM 节点或循环引用，dispatchEvent会抛DataCloneError - 调试时，
event.detail在开发者工具的 Event Listeners 面板里可展开查看；dataset得去 Elements 面板查属性
stopPropagation 和 stopImmediatePropagation 的实际影响差异
两者都中断传播，但作用范围不同：前者只拦后续节点，后者连同级监听器也跳过。
-
event.stopPropagation()：阻止冒泡/捕获继续，但同一元素上其他click监听器仍会执行 -
event.stopImmediatePropagation()：不仅停传播，还跳过当前元素上剩余所有同类型监听器（按注册顺序） - 常见误用：在自定义事件监听里调
stopImmediatePropagation()后又期望父级监听器运行——它其实已经把整个事件流掐断了
跨组件通信时，事件目标应明确限定在 document 或 custom element 上
避免用 body 或 div#app 当中转站，它们易受 DOM 变更影响；document 是稳定锚点，custom element 则自带封装边界。
- 全局通信用
document.dispatchEvent()+document.addEventListener()，但要加命名空间前缀（如myapp:login-success）防冲突 - 组件内通信优先用 custom element 的
this.dispatchEvent()，父组件监听this.shadowRoot或直接监听该元素实例 - 绝对不要监听
window上的自定义事件——它无法被stopPropagation拦截，且与页面生命周期强耦合
真正难的不是 dispatch 一次事件，而是确保监听器在销毁时被移除、detail 数据不越界、bubbles 设置不遗漏——这些细节在热更新或动态组件场景下最容易出问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
