Shadow DOM 不提供文档结构硬隔离，仅隔离样式和 DOM 查询边界；其 shadow tree 仍属主 document，故 document.querySelector 等 API 可跨 boundary 访问内部元素，事件也默认冒泡穿透，真正实现结构硬隔离须用 iframe。
Shadow DOM 本身不提供“文档结构硬隔离”，它只隔离样式作用域和 DOM 查询边界——document.querySelector 在 shadow root 外查不到内部元素，但 document.body、document.getElementById 仍能穿透；结构上，shadow tree 是主文档 DOM 的子树，不是独立文档。所谓“硬隔离”是误用概念，真正能切断结构关联的只有 <iframe>。
为什么 attachShadow 后 document.querySelector 还能跨 boundary 查到内容
Shadow DOM 不改变文档层级归属：shadow root 是宿主元素的子节点，整个 shadow tree 仍属于同一 document 实例。所以：
-
document.querySelector('#my-id')能命中 shadow 内部带 id 的元素（只要该 id 全局唯一） -
document.body.contains(element)对 shadow 内元素返回true - 事件如
click默认冒泡穿过 shadow boundary，event.composedPath()仍含 shadow 内节点
这不是 bug，是规范行为。想阻止结构可见性，必须放弃 Shadow DOM，改用 <iframe sandbox="allow-scripts">。
如何让 shadow 内元素对 document 级 API “不可见”
无法完全隐藏，但可大幅削弱暴露面：
立即学习“前端免费学习笔记（深入）”；
- 禁用全局 ID：避免在 shadow 内使用
id属性，改用data-id或 class - 关闭事件冒泡：所有内部事件监听加
{ composed: false }，例如button.addEventListener('click', handler, { composed: false }) - 不用
document.createElement创建 shadow 内节点：统一用shadowRoot.ownerDocument.createElement，避免意外挂到主 document - 禁止从 shadow 内调用
document.querySelector或document.getElementById—— 改用shadowRoot.querySelector
注意：document.querySelectorAll('*') 仍会返回 shadow 内元素，这是浏览器实现决定的，无法绕过。
什么场景下必须用 iframe 而非 Shadow DOM
当需求明确要求“结构级隔离”时，比如：
- 第三方广告代码，不允许其读取或修改宿主页面任何 DOM 节点
- 用户提交的 HTML 预览，需防止
document.write、location.href = 'javascript:...'等危险操作 - 微前端子应用，要求 JS 执行环境、history、storage 完全独立
此时 <iframe srcdoc="<div>...</div>" sandbox="allow-scripts"> 是唯一合规方案。Shadow DOM 在这类场景下只是“样式防污染层”，不是安全沙箱。
真正要实现结构硬隔离，就得接受 iframe 带来的通信成本、SEO 限制和 DOM 直连中断——Shadow DOM 没有妥协空间，它根本就不是为这个目标设计的。
