如何构建高度隔离且不可篡改的UI组件，仅用Shadow DOM的closed模式？

本文共计806个文字，预计阅读时间需要4分钟。

closed模式无法构建UI组件——它只能阻止通过element.shadowRoot属性直接访问影子树，但无法防御事件监听、CSS注释、DOM快照、未消亡的HTML渲染等常见绕过方式。真正提升隔离强度，依赖的是组合策略，而非仅仅依赖于mode:。

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 当作“防君子不防小人”的轻量门槛可以，但别把它当作安全终点。