Shadow DOM 本身不提供沙箱测试能力，仅隔离样式与DOM查询；真实沙箱测试须依赖 iframe、CSP 等浏览器原生机制协同实现，否则 jest/jsdom 环境中 attachShadow 失效、::slotted/:host 不计算、样式断言失败。
Shadow DOM 本身不提供沙箱测试能力，它只负责样式和 DOM 查询隔离；真正的沙箱测试必须依赖浏览器原生机制（如 iframe、CSP）与 Shadow DOM 协同构建，否则测试环境与生产环境行为严重脱节。
为什么直接用 Shadow DOM 做单元测试会失败
常见错误是把 jest 或 jsdom 环境里渲染的自定义元素当成真实沙箱——但 jsdom 不支持 attachShadow() 的完整语义，shadowRoot 返回空或抛错，::slotted 样式不计算，:host 伪类被忽略。
-
document.createElement('my-button').attachShadow({ mode: 'open' })在 jsdom 中返回null或无功能 root，导致后续shadowRoot.querySelector失败 - 测试中写
el.shadowRoot.innerHTML = '<style>span{color:red}</style>'，实际未注入 CSSOM，断言getComputedStyle(span).color永远是默认值 -
DOMParser解析含<slot></slot>的 HTML 字符串后，slot.assignedNodes()在 jsdom 中始终为空，无法验证内容分发逻辑
在真实浏览器中做沙箱测试的实操路径
真正可靠的沙箱测试只能跑在 Chromium 或 Firefox 的真实渲染上下文中，且需绕过 DevTools 默认隐藏 Shadow DOM 的限制。
- 启用 Chrome DevTools 的 Show user agent shadow DOM 选项（Settings → Preferences → Elements），否则
<my-card>节点下看不到#shadow-root (open)展开项 - 测试脚本中必须显式调用
element.attachShadow({ mode: 'open' })，禁用'closed'—— 否则element.shadowRoot为null，所有基于 shadowRoot 的断言都失效 - 验证样式隔离：在测试页全局写
button { background: blue !important; }，再用expect(getComputedStyle(buttonInShadow)).toBe('red')断言未被覆盖 - 验证 slot 分发：向组件传入
<my-card><p slot="title">Test</p></my-card>，再查shadowRoot.querySelector('[slot="title"]').textContent是否匹配
如何让插件类组件支持可测沙箱环境
若组件需加载远程 HTML/CSS/JS 并注入 Shadow DOM，测试时必须模拟资源加载链路，不能假设网络就绪。
立即学习“前端免费学习笔记（深入）”；
- 用
fetchMock 拦截插件资源请求，返回预构造的 HTML 字符串（含<style>和<script type="module">） - 注入前用
DOMParser解析字符串，遍历提取所有<style>标签，转为document.createElement('style')并shadowRoot.appendChild()—— 避免innerHTML = html导致内联脚本逃逸执行 - 对动态生成的
@keyframes，测试前用正则替换为带唯一前缀的版本（如@keyframes test-plugin-spin），防止多个测试用例间动画名冲突 - 测试完成后，在
afterEach中手动清理：shadowRoot.innerHTML = ''+document.adoptedStyleSheets = []，避免样式残留影响下一个用例
Shadow DOM 的测试难点不在 API 调用，而在边界行为验证：slot 是否正确分发、:host-context() 是否响应祖先 class 变化、adoptedStyleSheets 是否真正作用于该 root。这些都要求测试运行在真实渲染引擎中，且必须暴露 shadowRoot 接口——任何试图用 jsdom 或“模拟 shadow”绕过这一步的方案，最终都会在 CI 环境里暴露出样式穿透或事件丢失的问题。
