event.target总是宿主元素是因为Shadow DOM事件重定向机制,浏览器为封装性将内部事件目标自动改为宿主元素;真实目标需用event.composedPath()[0]获取,跨边界通信须派发bubbles:true且composed:true的自定义事件。
Shadow DOM 内部触发原生事件(如 click)时,浏览器会自动重定向 event.target,使其指向宿主元素(比如 <my-button>),而非内部真实的 <button>。这不是 bug,是隔离设计的一部分——防止外部逻辑意外依赖影子树细节。
常见错误现象:event.target.classList.contains('btn') 总是 false;用 querySelector 找不到影子树内节点,却误以为事件没触发。
event.composedPath()[0]:它在 Shadow 内外都返回原始触发元素onclick,改用自定义事件通信event.target === event.composedPath()[0] 在 Shadow 内部为 true,外部为 false,可用来做环境判断原生事件(click、input、change)默认 composed: false,不可修改,也无法穿透边界。所谓“让事件冒泡出去”,本质是主动派发一个 composed: true 的自定义事件。
实操建议:
立即学习“前端免费学习笔记(深入)”;
element.dispatchEvent(new CustomEvent('ui-submit', { bubbles: true, composed: true }))
document.addEventListener('ui-submit', handler) 就能收到composed: true 是最常见错误——事件发出去了,但停在 shadow boundary,外部完全收不到click 设置 composed: true:属性只读,且语义上不应穿透通过 <slot> 投影进来的节点(比如外部传入的 <span onclick="...">),其事件仍遵循 Shadow DOM 的重定向规则。即使内容在视觉上“显示在组件内部”,事件的 target 和冒泡路径仍受影子边界约束。
使用场景举例:一个卡片组件接收外部传入的操作按钮,希望点击后通知父级。
shadowRoot 中监听 slot 的 slotchange,然后对其中的可交互节点手动绑定事件,并转发为 composed: true 的自定义事件::slotted(*) 只能控制投影内容的样式,不能改变其事件行为这通常不是监听器没绑上,而是事件根本没到达监听位置——可能卡在 Shadow boundary,也可能监听对象错了。
排查要点:
document.body 却忘了注册名是否拼错(比如监听 'submit' 但 dispatch 的是 'form-submit')mode: 'closed' 会导致 element.shadowRoot === null,调试困难,生产环境慎用connectedCallback 里绑定事件,别在 constructor 里操作 shadowRoot(此时还未创建)<input type="range">)的内部结构,否则容易误判事件来源Shadow DOM 的事件机制不是“开关式穿透”,而是一套需要显式声明意图的通信契约。最容易被忽略的,是把 composed: true 当作可选参数——它其实是跨边界通信的准入凭证,缺了就等于没发出去。