closed模式仅使element.shadowRoot返回null，无法阻止DevTools查看、DOM快照、反射调用、事件监听等外部读取；真正隔离需组合composed: false、:host控制、slot精确开放与HTML净化。
closed 模式不能防止外部“直接访问”——它只让 element.shadowRoot 返回 null，而所有常见访问方式（DevTools 查看、DOM 快照、反射调用、事件监听）依然有效。
为什么 mode: 'closed' 无法阻止外部读取内部结构
设置 attachShadow({ mode: 'closed' }) 后，唯一变化是 element.shadowRoot 属性返回 null。但浏览器开发者工具（Chrome/Firefox）仍可展开宿主元素，完整显示 Shadow Tree；第三方监控 SDK 调用 el.cloneNode(true) 也会复制整个影子树；甚至通过反射也能绕过：
Object.getOwnPropertyDescriptor(HTMLElement.prototype, 'shadowRoot').get.call(element)
这行代码在 closed 模式下仍能拿到真实的 ShadowRoot 对象。更关键的是：querySelector、addEventListener 等 API 完全不受影响——外部仍可监听内部按钮的点击事件，或通过 el.querySelector('slot') 猜测结构路径。
closed 模式下写 shadowRoot.querySelector 必然报错
这是最常踩的坑：开发者误以为 “只要设成 closed，内部逻辑就安全了”，结果在组件自身代码里还写：
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
this.shadowRoot.querySelector('input')——在 closed 模式下，this.shadowRoot 就是 null，这行代码直接抛出 TypeError: Cannot read property 'querySelector' of null。正确做法是：
- 始终在
constructor或connectedCallback中确认this.shadowRoot存在（即只在 open 模式下初始化） - 所有 DOM 查询必须基于
this.shadowRoot，且不能假设它非空 - 避免在组件内使用
document.querySelector查找自身节点，否则可能误命中 light DOM 元素
Jest + jsdom 根本不支持 closed，测试会彻底失效
jsdom（Jest 默认环境）完全未实现 Shadow DOM，closed 模式下连 element.attachShadow 都可能返回 undefined 或静默失败。这意味着：
- 单元测试只能跑在
open模式下，而线上切closed—— 行为不一致，CI 过了线上仍可能崩 - 无法 mock 或 inspect 内部状态，断言逻辑（如“输入框是否被禁用”）根本写不出来
- 若强行用 Puppeteer 做 E2E 测试 closed 组件，启动慢、不稳定、维护成本高
实际项目中，绝大多数团队最终都退回到 mode: 'open' 并靠设计保障隔离性。
真正影响隔离强度的不是 mode，而是这四件事
想让组件“不被干扰”，重点不在锁住 shadowRoot 属性，而在控制行为边界：
- 所有自定义事件派发时显式加
composed: false，否则事件照样冒泡到 light DOM - 用
:host和:host-context()控制样式入口，禁用全局重置类（如* { all: initial }） - 只通过
<slot name="xxx"></slot>+exportparts="xxx"精确开放必要节点，不暴露整棵树 - 对传入的 HTML 字符串做严格净化（如
DOMPurify.sanitize()），closed对 XSS 零防护
closed 模式唯一的合理用途，是配合 iframe + strict CSP 构建微前端沙箱——单靠它，什么都防不住。
