Shadow DOM 的 closed 模式不提供强主权保护，仅使 shadowRoot 返回 null；真正沙箱需 iframe、Strict CSP 和 Shadow DOM 协同，推荐 open 模式配合显式契约与三层防线。
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 容器：将插件挂载在独立
<iframe sandbox="allow-scripts"></iframe>中，隔离全局对象（window、document）、禁止弹窗与表单提交 -
Strict CSP：响应头中配置
Content-Security-Policy: default-src 'self'; script-src 'wasm-unsafe-eval'; object-src 'none'，禁用内联脚本与 eval -
Shadow DOM 配合 :host-context()：限制外部样式仅在特定上下文生效，避免被页面级
* { display: none !important }破坏布局
closed 模式仅在极有限场景下可辅助使用
除非同时满足以下全部条件，否则不应启用 closed：
- 插件运行于浏览器扩展 content script 环境，且宿主页面存在已知恶意脚本
- 已部署 iframe + CSP + HTML 净化三层防护，
closed仅作为最外层混淆手段 - 团队具备 Puppeteer/Playwright E2E 测试能力，能覆盖真实 closed 行为，不依赖 jsdom 单元测试
- 明确接受调试成本上升——DevTools 中无法 inspect shadow root，所有问题必须通过组件公开 API 日志定位
