Shadow DOM 闭合模式构建插件沙箱方法

Shadow DOM 的 closed 模式并非真正的沙箱保护机制，它仅表面屏蔽 shadowRoot 访问，却无法阻止开发者工具查看、DOM 快照提取、结构推断、事件冒泡和 CSS 注入等绕过行为；构建高主权插件沙箱必须摒弃对 closed 的误信，转而采用 open 模式配合显式契约设计（如封装操作方法、限制事件传播、重置样式继承、严格输入校验），并强制落地 iframe 隔离、Strict CSP 策略与 Shadow DOM 协同的三层防线——这才是面向生产环境、可调试、可测试且真正抵御恶意宿主的沙箱实践。

Shadow DOM 的 closed 模式无法提供“强主权保护”的实际能力，它仅让 element.shadowRoot 返回 null，不构成有效沙箱边界。真正具备主权保护的插件沙箱必须依赖多层协同机制，而非单靠 mode: 'closed'。

closed 模式在沙箱中起不到主权防护作用

设置 { mode: 'closed' } 后，外部脚本调用 el.shadowRoot 确实返回 null，但这只是屏蔽了标准访问路径。以下行为均不受影响：

• 浏览器开发者工具（Chrome/Firefox）默认可展开并查看完整 Shadow DOM 结构，无需任何权限绕过
• el.cloneNode(true) 生成的 DOM 快照仍包含全部 shadow tree 内容
• 外部可通过 el.querySelector('slot')、el.children 或 el.getAttribute('data-xxx') 推断内部结构
• 事件冒泡照常发生，document.addEventListener('click', handler) 仍能捕获内部按钮触发的点击
• CSS 仍可借助 ::part()（配合 exportparts）或 ::slotted() 实现样式注入

构建插件沙箱应优先采用 open + 显式契约

插件运行环境不可控，但“可控暴露”比“虚假隐藏”更可靠。推荐以 mode: 'open' 为基础，通过设计约束实现主权：

• 所有内部节点操作封装为组件方法（如 setConfig()、triggerExport()），不暴露原始 DOM 引用
• 关键事件派发时强制指定 composed: false，阻断跨 boundary 监听
• 宿主元素使用 :host { all: initial; } 重置继承，再按需声明允许的 CSS 自定义属性
• 对外只接受 JSON/PlainObject 类型参数，拒绝 HTML 字符串；若需渲染内容，先经 DOMPurify.sanitize() 过滤

真正提升主权的三道必要防线

单一 Shadow DOM 无法形成沙箱，必须组合以下机制：

• iframe 容器：将插件挂载在独立