closed模式仅使shadowroot返回null，无法防御事件冒泡、css注入、dom快照或xss等攻击；真正隔离需组合composed: false、slot/exportparts、dompurify等策略，open模式更利于测试与维护。
closed 模式不能构建“不可被外部脚本篡改”的 UI 组件——它只阻止通过 element.shadowRoot 属性直接访问影子树，但无法防御事件监听、CSS 注入、DOM 快照、未消毒的 HTML 渲染等常见绕过方式。真正提升隔离强度，靠的是组合策略，而非仅依赖 mode: "closed"。
closed 模式的真实能力与局限
调用 attachShadow({ mode: "closed" }) 后，el.shadowRoot 始终返回 null，这是它唯一生效的行为。但它不改变以下事实：
- 开发者工具仍可完整查看和编辑 Shadow DOM 结构（Chrome、Firefox 均支持）
- 外部样式可通过
::part()或::slotted()（若组件显式开放）影响内部节点 - 未设
composed: false的自定义事件会自然冒泡到 light DOM，可被document.addEventListener捕获 - 组件若使用
innerHTML插入用户输入内容，且未经 DOMPurify 等清洗，仍存在 XSS 风险
比 closed 更关键的隔离实践
很多团队误以为设成 closed 就“安全了”，其实真正起效的防护都在组件内部逻辑中：
- 所有
this.dispatchEvent(new CustomEvent(...))都应显式传入{ composed: false }，防止行为意图泄露 - 避免用全局重置样式如
* { all: initial }；改用:host和:host-context()精准控制宿主状态与主题适配 - 需要对外暴露的子节点（如按钮、输入框），统一用
<slot name="control"></slot>+exportparts="control"，而不是把整个 shadowRoot 暴露出去 - 对任何动态插入的 HTML 字符串，必须先调用
DOMPurify.sanitize(html)，不能依赖 Shadow DOM 自动过滤
常见误用与正确写法对比
下面这段代码在 closed 模式下必然失败，但错误常被归因为“Shadow DOM 不工作”：
const el = document.querySelector('#my-component');
console.log(el.shadowRoot); // null —— 不报错，静默失效
console.log(el.shadowRoot.querySelector('input')); // TypeError更隐蔽的问题是：组件内部若写 document.querySelector('.input')，可能意外选中 light DOM 中同名元素，导致功能错乱。正确做法是：
- 始终用
this.shadowRoot.querySelector(...) - 在构造函数中检查
this.shadowRoot是否存在（仅 open 模式下非 null） - 若坚持用 closed，需确保所有内部 DOM 操作都基于 this，且不依赖外部访问路径
实际建议：优先用 open，再靠设计加固
绝大多数生产组件推荐 mode: "open"，原因很实在：
- 便于自动化测试（Puppeteer、Playwright 可直接查询 shadowRoot）
- 方便调试与 QA 验证，降低维护成本
- 真正的隔离强度来自事件策略、样式范围控制、HTML 消毒等组合措施，而非隐藏入口
把 closed 当作“防君子不防小人”的轻量门槛可以，但别把它当作安全终点。
