Shadow DOM 不阻止 document.querySelector 查询内部元素，因其节点仍属主 document；真正隔离需主动收束作用域，如用 shadowRoot.querySelector、禁用 ID、事件设 composed: false。
Shadow DOM 本身不阻止 document.querySelector 查到内部元素——它查的仍是主文档全局 DOM，不是隔离失效，而是你没限制查询范围。真正防 DOM 查询污染，靠的是“主动收束作用域”，不是“被动隐藏结构”。
为什么 document.querySelector 还能穿透 Shadow DOM？
因为 shadow tree 仍是主 document 的一部分：所有节点都归属同一个 document 实例，document.getElementById、document.querySelectorAll('*') 照常返回 shadow 内元素。这不是 bug，是规范行为。浏览器只隔离样式计算和默认查询入口（如 element.querySelector），不隔离全局 document API。
-
document.querySelector('#ad-close')能命中 shadow 内带该 id 的按钮，只要 id 全局唯一 -
document.body.contains(shadowEl)返回true，说明结构上未脱离主文档 - 事件默认
composed: true，冒泡路径仍含 shadow 内节点，event.composedPath()可见
必须用 shadowRoot.querySelector 替代 document.querySelector
所有对 shadow 内部的 DOM 操作，必须显式以 shadowRoot 为起点。这是唯一可靠、可维护的查询方式。
- 禁止在组件逻辑中写
document.querySelector('.btn')—— 即使它“碰巧”能查到，也等于向全局泄漏查询意图 - 推荐封装一个作用域安全的查询函数：
const $ = (sel) => shadowRoot.querySelector(sel) - 若用 jQuery，初始化时必须传入上下文：
$(shadowRoot).find('.close-btn')，不能依赖全局$() - 第三方库（如 Foundation、Quill）初始化时，必须显式传入
shadowRoot或其子节点，否则它们内部仍会调用document
避免 ID 泄漏与事件穿透带来的间接污染
ID 是全局命名空间，一旦 shadow 内用了 id="header"，就可能被主站其他脚本误匹配；事件冒泡则让外部监听器“感知”到内部操作，形成逻辑耦合。
- 禁用
id属性：改用data-id或class，或由宿主元素统一管理 ID 分配 - 所有内部事件监听加
{ composed: false }，例如：button.addEventListener('click', handler, { composed: false }) - 自定义事件 dispatch 时显式设
composed: false：el.dispatchEvent(new Event('loaded', { bubbles: true, composed: false })) - 不要在 shadow 内调用
document.createElement—— 改用shadowRoot.ownerDocument.createElement，防止节点意外挂到主 document
真正的 DOM 查询隔离，不在于让元素“看不见”，而在于让开发者“无法顺手写错”。一旦允许裸调 document.querySelector，哪怕只有一处，整个组件的封装边界就形同虚设。最易被忽略的，是第三方库初始化时没传作用域，以及事件监听忘记 composed: false —— 它们不会报错，却在运行时悄悄破坏隔离。
