Web组件派发自定义事件：应选择this还是window作为派发对象？

核心差异 #

• 传播边界完全不同
  用组件实例this.dispatchEvent()派发的事件严格遵循DOM事件流规则：默认情况下事件仅在组件自身节点触发，配置bubbles: true后会沿DOM树向上逐级冒泡，配置composed: true才能穿出Shadow DOM边界，传播范围始终被限制在当前组件所在的DOM子树内，不会跑到无关的DOM分支上。
  用window.dispatchEvent()派发的事件属于全局广播，直接在顶层window对象触发，和DOM层级完全无关，页面内任何位置的脚本只要给window绑定了对应监听器都能收到，没有任何传播边界限制。
• 隔离性与冲突风险不同
  组件自身派发的事件天然和其他DOM分支的组件隔离，哪怕页面上有10个同类型组件同时派发同名事件，每个事件只会沿自己的DOM路径冒泡，不会出现串扰。
  window上派发的事件是全局共享的，只要事件名重复就会互相干扰，监听方无法默认区分事件来源，除非手动在detail字段里加组件标识，项目规模一大很容易出现同名事件冲突的问题。
• 引用获取与上下文不同
  组件实例派发的事件，event.target直接指向派发事件的组件本身，监听方可以直接通过target拿到组件实例，访问组件属性、调用组件方法，和原生button等HTML元素的事件行为完全一致。
  window派发的事件event.target永远是window对象，无法直接获取派发源的组件引用，必须主动把组件标识、相关数据塞进detail才能传递上下文。
• 内存泄漏风险不同
  组件自身派发的事件，监听器大多绑定在DOM节点上，跟随DOM节点移除会被自动回收，只要不是故意把监听器绑在全局对象上，泄漏风险极低。
  window上的监听器是全局常驻的，如果组件挂载时绑定了window事件、销毁时忘记手动解绑，哪怕组件实例已经被回收，监听器依然会留在内存里，后续触发时很容易执行已销毁组件的逻辑，抛出报错或者产生脏数据。
• 框架适配性不同
  对于Lit这类Web组件库，模板里的声明式事件绑定（比如@my-event=${handler}）是基于DOM事件流实现的，只能监听到DOM路径上冒泡过来的事件，根本接收不到直接派发到window上的事件，必须手动写addEventListener/removeEventListener才能对接，和框架的适配成本更高。

适用场景 #

组件实例派发（this.dispatchEvent()） #

这是Web组件自定义事件的默认推荐方案，覆盖90%以上的常规业务场景：

• 组件对外暴露的常规交互事件，比如自定义输入框的change、自定义选择器的select、自定义表单的submit等，只需要父组件/祖先组件感知的通信场景，行为和原生HTML元素事件完全一致，符合开发者的通用直觉。
• 多实例并存的组件场景，比如页面上同时渲染多个列表、多个表单，依靠DOM事件流天然隔离，不会出现不同组件实例的事件串扰。
• 需要配合Lit等框架声明式语法使用的场景，不用手动处理监听器的绑定和解绑，框架会自动在生命周期里完成相关操作。

window对象派发 #

仅在确实需要全局通信的特殊场景下使用：

• 真正的全局状态变更通知，比如用户登录态过期、全局主题切换、页面语言变更、全局错误提示等，整个应用任意位置的组件都可能需要响应的事件。
• 通信双方完全没有共同DOM祖先、跨DOM树的轻量通信场景，比如悬浮在页面顶层的弹窗组件、第三方嵌入的独立组件，和页面其他组件没有DOM层级关系，又不想引入额外全局状态管理方案的情况。
• 对接页面上独立的第三方SDK、非Web组件体系的传统脚本，对方只方便在全局window层面监听事件的场景。

选型判断标准 #

按优先级从高到低判断就行，别上来就图省事用全局事件：

1. 只要事件不需要被当前组件DOM子树之外的逻辑接收，直接选this.dispatchEvent()，这是原生Web组件设计的标准事件模式，和Lit生态适配最好，维护成本最低。
2. 如果需要跨多层DOM传递事件，优先给事件配置bubbles: true和composed: true（需要穿出Shadow DOM时加），让事件沿DOM树冒泡到共同的祖先节点处理，不要直接跳去发window事件。
3. 只有确认事件需要全应用范围任意模块接收、没有共同DOM祖先可以承接事件时，再考虑用window派发。这时候必须做两个防护：一是事件名加唯一命名空间前缀，比如app-global-user-expired，不要用logout这种太通用的名字避免冲突；二是所有绑定在window上的监听器，必须在组件的disconnectedCallback生命周期里手动解绑，避免内存泄漏。
4. 如果项目已经引入了全局状态管理、Lit Context这类跨组件通信方案，优先用现成的方案做跨层级通信，不要滥用window事件——全局事件流一旦多起来，根本追踪不到事件的派发源和流向，后续排查bug的成本会非常高。

踩坑提示：别为了省几行冒泡配置、或者不想一层层传事件就把所有事件都往window上挂，我见过不少项目维护到后期，window上光同名的自定义事件就有三四个，排查冲突的时候要翻半个仓库的代码，纯纯的技术债。

内容的提问来源于stack exchange，提问作者Steve Kalemkiewicz