影子 DOM - 面试题

#

★★★

1. ::part 与 CSS Variables 在 Shadow DOM 外部样式穿透的工程价值

问题

请说明 ::part 与 CSS Variables 在 Shadow DOM 外部样式穿透中的机制，以及它们的工程价值？

考察点

::part 暴露内部命名部件供外部定制
CSS 变量沿继承链穿透 Shadow 边界
两者在主题系统的协作与取舍

答案

::part 与 CSS 变量是 Shadow DOM 提供外部样式穿透的两大受控通道。::part(name) 允许外部精确选择组件内部用 part 属性标记的命名部件并覆盖样式，是"结构性"定制接口；CSS 变量（自定义属性）沿继承链从宿主穿透到影子内部，组件内部通过 var() 引用，实现"变量化"的主题定制。工程价值：组件库用 CSS 变量定义主题 tokens（颜色、间距、圆角），用户只需在宿主上覆盖变量即可整体换肤；结合 ::part 做细粒度结构定制。二者互补：CSS 变量适合全局主题与批量定制，::part 适合单部件精确覆盖，都保持封装边界不破坏内部结构。

解析

这是封装与定制的平衡设计。CSS 变量是"价值观"定制、::part 是"结构定位"定制，用户无需深入组件内部即可实现主题与局部覆盖，是设计系统主题化的支柱。

示例代码

/* 组件内部 */
:host { --accent: #0066ff; }
button { background: var(--accent); }

/* 外部 */
my-card { --accent: #ff6600; }
my-card::part(header) { padding: 12px; }

#

★★★

2. Shadow DOM 的闭合性（:host/::slotted/::part）

问题

请说明 Shadow DOM 的闭合性机制，即 :host、::slotted、::part 三个选择器如何作用在 Shadow 边界上？

考察点

:host 选择宿主元素
::slotted 选择投射的插槽内容
::part 选择内部命名部件

答案

Shadow DOM 的闭合性体现在外部样式不能直接穿透选择内部节点，但规范提供了三个边界选择器：:host 在影子内部选择宿主元素，用于给组件容器设置样式，也可被外部样式覆盖；::slotted(selector) 在影子内部选择投射进来的插槽内容（light DOM），用于样式化填充内容；::part(name) 在外部选择组件内部标记了 part 的部件，用于外部定制。三者共同构成"闭合但有开口"的封装模型：默认隔离、显式开洞。工程上分别用于组件自身样式、插槽内容样式、外部定制部件。

解析

这是理解 Shadow DOM 封装的关键。闭合性不等于完全隔离，:host/::slotted/::part 是三个受控的"开口"，每个开口的用途与作用方向不同，规范设计就是为了在隔离与定制间取得平衡。

#

★★★

3. Shadow DOM 中的 :host 与 :host-context 的样式继承与重写

问题

请说明 Shadow DOM 中 :host 与 :host-context 的作用，以及它们与样式继承、重写的关系？

考察点

:host 选择宿主元素并设置样式
:host-context 依据外部祖先选择
样式继承与外部重写优先级

答案

:host 在 Shadow DOM 内部选择宿主元素，可设置组件自身的样式（如 display、布局），也可用 :host(.class) 依据宿主上的类选择；:host-context(selector) 依据外部祖先是否匹配 selector 来选择宿主，用于响应外部上下文（如暗色模式、主题类）。样式继承上，可继承属性穿透边界，:host 可显式继承（如 color: inherit）以配合外部主题；外部样式对宿主的覆盖优先级通常高于影子内部 :host 规则（外部针对性更强）。工程上 :host 用于组件默认样式，:host-context 用于感知外部环境，组合实现主题与上下文响应。

解析

:host 是影子内部定义宿主样式的入口，:host-context 是"上下文感知"的受控方式。注意 :host-context 与外部覆盖的优先级规则，理解"外部>内部"的级联能在主题系统协作时正确预期。

示例代码

:host { display: block; }
:host(.active) { color: blue; }
:host-context(.dark) { background: #111; }

#

★★★

4. Slot 插槽（）与 Web Components 组合

问题

请说明插槽机制与 Web Components 组合（composition）的关系？

考察点

具名/默认插槽的投射机制
组合与"内容归属"的关系
插槽在组件组合中的工程价值

答案

Slot 是 Web Components 组合的核心机制。组件在 Shadow DOM 中声明作为插入点，外部 light DOM 中带 slot="x" 的子元素被"投射"到该位置，未匹配的子元素进入默认插槽。投射是逻辑上的组合，light DOM 节点仍归属外部文档，仅渲染位置被包进影子树。这使组件能像原生元素一样接受任意内容并组合呈现，实现可扩展的组件 API（如 Card 的 header/body/footer 插槽、Layout 的分布插槽）。工程上 Slot 让组件"内容由使用者提供、结构由组件决定"，是设计可复用组件库的基础。

解析

组合强调"内容与结构的分离"，是 Web Components 相比框架组件封装的独特优势。理解投射（非移动）语义避免误操作 light DOM 节点导致插槽失效，是组合工程实践的前提。

示例代码

<!-- 组件内部 -->
<div class="card">
  <header><slot name="title">默认</slot></header>
  <div><slot></slot></div>
</div>

<!-- 使用 -->
<my-card><span slot="title">标题</span>正文</my-card>

#

★★★

5. form-associated custom elements，formAssociated 标志与 ElementInternals（setFormValue、setValidity）如何让 Shadow DOM 自定义控件参与原生表单提交与校验？

问题

请说明 form-associated 标志与 ElementInternals（setFormValue、setValidity）如何让 Shadow DOM 自定义控件参与原生表单提交与校验？

考察点

formAssociated 静态标志
setFormValue 参与表单提交
setValidity 参与原生校验

答案

通过声明 static formAssociated = true 并调用 attachInternals() 获取 ElementInternals，自定义元素即可成为"表单关联"控件，参与原生表单语义。setFormValue(value, state) 设定提交值，使控件值随表单提交被收集进 FormData；setValidity(flags, message, anchor) 设置校验状态（如 valueMissing、tooShort），配合表单的 :invalid、:valid 伪类与原生校验流程，浏览器可基于该状态阻止提交并显示校验消息。这使 Shadow DOM 内部的自定义输入控件在提交、校验、表单状态上与原生 input 一致，无需手动拦截 submit，是构建真实表单控件组件的关键。

解析

formAssociated 把"影子内部控件"提升为"原生表单成员"，是 Web Components 表单集成的基石。setFormValue 与 setValidity 分别解决"提交什么"与"是否合法"，组合实现完整的表单交互。

示例代码

class FancyInput extends HTMLElement {
  static formAssociated = true;
  #internals;
  constructor() { super(); this.#internals = this.attachInternals(); }
  update(value) {
    this.#internals.setFormValue(value);
    this.#internals.setValidity(value ? {} : { valueMissing: true }, '必填');
  }
}

#

★★

6. Shadow DOM 的事件重定向与 composedPath

问题

请说明 Shadow DOM 的事件重定向机制与 composedPath 的应用？

考察点

事件重定向（target 重定向为宿主）
composed 标志与跨边界冒泡
composedPath 事件溯源

答案

当 Shadow DOM 内部节点触发事件并冒泡到宿主层级时，事件会被"重定向"：事件阶段的外部 target 被改为宿主元素而非内部节点，除非未设置 composed。composed 标志决定事件是否能跨过 Shadow 边界继续冒泡到文档；普通事件默认 composed 为 false 时不会越过边界，而 focus、click 等用户交互事件通常 composed: true。composedPath() 返回事件传播经过的完整节点路径（含内部 shadow 节点），用于事件溯源。工程上，自定义元素用 composed: true 的自定义事件向上传递动作，监听方用 composedPath 判断事件是否来自特定内部节点（如点击了内部按钮）。

解析

事件重定向与 composedPath 是事件跨 Shadow 边界的核心。重定向让外部监听者拿到稳定的宿主 target，composedPath 提供内部细节，二者结合实现"外部感知 + 内部溯源"，是自定义元素事件编程的必备知识。

示例代码

this.dispatchEvent(new CustomEvent('x-selected', { bubbles: true, composed: true }));
document.addEventListener('x-selected', (e) => {
  const path = e.composedPath(); // 含 shadow 内部节点
});

#

★★

7. Scoped Element Registries 提案（多版本同名自定义元素共存）在微前端与组件库升级中的工程价值

问题

请说明 Scoped Element Registries 提案如何让多版本同名自定义元素共存，以及它在微前端与组件库升级中的工程价值？

考察点

提案解决全局注册表冲突
影子根级作用域注册
微前端与组件库升级中的应用

答案

当前自定义元素注册表是全局单例，同名元素只能注册一次，导致多版本同名组件或微前端多应用冲突。Scoped Element Registries 提案允许在 shadowRoot 上建立独立作用域的自定义元素注册表，使不同影子根内可注册同名不同版本的自定义元素，实现多版本共存。工程价值：微前端中每个子应用可注册自己版本的组件而不互相污染；组件库升级时可在作用域内保留旧版本并逐步迁移，避免全量升级的破坏性；同时支持按需延迟加载元素定义。它让自定义元素从"全局单例"走向"局部作用域"，是解决规模与隔离问题的关键演进。

解析

全局注册表是当前 Web Components 主要局限之一，Scoped Element Registries 提供作用域级隔离。对微前端与大型组件库，作用域注册避免命名冲突与版本地狱，是预防性架构的重要方向。

#

★★

8. Shadow DOM 的开放（open）与封闭（closed）

问题

请说明 Shadow DOM 的 open 与 closed 模式的区别与取舍？

考察点

open 模式与 shadowRoot 可访问
closed 模式与 shadowRoot 不可访问
两种模式的工程取舍

答案

attachShadow({ mode: 'open' }) 创建开放影子根，元素实例的 shadowRoot 属性对外可访问，外部脚本可读取内部 DOM、样式与事件；attachShadow({ mode: 'closed' }) 创建封闭影子根，shadowRoot 属性返回 null，外部无法直接访问，需在组件内部保存引用。工程取舍：open 模式便于调试、测试、可被外部工具访问，是绝大多数组件库的默认选择；closed 模式提供更强的封装与 API 保护，但规范不保证绝对安全（可通过 attachShadow 的 getter 或已存引用突破），且影响可调试性与可测试性，故较少使用。工程上默认 open，仅在明确需要保护内部实现时用 closed，并权衡调试成本。

解析

两者的核心差异是"内部是否可被外部访问"。closed 的"安全"更多是规范的建议而非强保证，且损失可测试性，多数团队倾向 open 模式 + 良好 API 约定来平衡。

#

★★

9. Declarative Shadow DOM 与流式 SSR/hydration 的配合，服务端渲染自定义元素的工程实现

问题

请说明 Declarative Shadow DOM 如何与 SSR/hydration 配合，实现服务端渲染自定义元素的工程实现？

考察点

声明式影子 DOM
服务器输出与客户端 attachShadow 的衔接
流式 SSR 与 hydration 的配合

答案

Declarative Shadow DOM（DSD）允许在 HTML 中用 <template shadowrootmode="open"> 声明影子根及其内容，服务器可直接输出带影子 DOM 的 HTML，无需客户端 JS 构造。新浏览器由解析器自动识别并创建 shadow root，客户端再通过自定义元素升级接管逻辑。与流式 SSR 配合：服务器可按需流式输出带 DSD 的组件 HTML，实现首屏即渲染完成；hydration 阶段只有事件与动态逻辑需要 JS。工程上，DSD 让自定义元素可被搜索引擎索引、无 JS 时可读，并减少首屏 JS 执行，是服务端渲染 Web Components 的关键，但需注意浏览器兼容并通过 polyfill/升级处理。

解析

DSD 解决"SSR 无法渲染 Shadow DOM"的痛点，让服务端输出与客户端升级无缝衔接。流式 SSR 下 DSD 可随 HTML 流式产出，配合 hydration 实现"先呈现、后增强"。

示例代码

<my-card>
  <template shadowrootmode="open">
    <style>h2{color:red}</style>
    <h2>Hello</h2>
  </template>
</my-card>

#

★★

10. Shadow DOM 的 :host(:hover) 与 :host-context() 在组件状态的应用

问题

请说明 :host(:hover) 与 :host-context() 在组件状态与上下文中的应用？

考察点

:host(:hover) 响应宿主交互状态
:host-context() 响应外部上下文
状态与上下文样式的组合

答案

:host(:hover) 在影子内部根据宿主元素的交互状态（如 hover、focus、active）选择宿主，用于实现组件自身的交互反馈样式，如悬停变色、焦点环；:host-context(selector) 依据外部祖先元素是否匹配 selector 选择宿主，用于响应外部上下文，如深色主题、特定容器。两者结合既可表达组件内部状态（hover/focus），又可感知外部环境（主题、布局语境），且不破坏 Shadow 封装。工程上 :host(:hover) 用于组件默认交互样式，:host-context 用于主题/上下文响应式样式，与应用框架的 class 环境协作。

解析

这两个选择器把"状态"与"上下文"纳入影子内部的可样式化维度，是组件实现状态样式与主题感知的受控方式。注意 :host-context 匹配的是外部祖先，而非内部元素。

示例代码

:host(:hover) { opacity: 0.8; }
:host(:focus-visible) { outline: 2px solid blue; }
:host-context(.dark) { background: #222; }

#

★★

11. Shadow DOM 的 fallback 内容与 named slot 的工程取舍

问题

请说明的 fallback 内容与具名插槽的机制，以及在设计组件时的工程取舍？

考察点

slot fallback 内容（未分配时显示）
具名/默认插槽的使用
插槽设计对组件 API 的影响

答案

元素内的内容作为 fallback：当没有匹配的 light DOM 节点被投射时显示，用于提供默认展示；一旦有节点进入，fallback 被替换。具名插槽（name="x"）满足按需分布内容，默认插槽接收其余内容。工程取舍：fallback 让组件在无内容时也有合理默认，避免空态；具名插槽设计决定组件 API 的灵活度，插槽数量与命名需匹配组件结构（如 header/footer/body）。设计时应权衡：插槽过细增加使用成本，过粗限制定制；fallback 应提供语义默认而非空占位。合理使用插槽与 fallback 提升组件可组合性与可用性。

解析

slot fallback 是"无内容时的默认"，named slot 是"按需分布"。工程上要基于组件结构设计恰到好处的插槽，并善用 fallback 提供默认态，是组件 API 设计的重要部分。

示例代码

<div class="modal">
  <header><slot name="title">默认标题</slot></header>
  <div><slot>无内容</slot></div>
</div>

#

★★

12. Shadow DOM 的 getRootNode() 与 composedPath() 在事件溯源的工程实践

问题

请说明 getRootNode() 与 composedPath() 在事件溯源与跨边界编程中的工程实践？

考察点

getRootNode 获取根节点（含 shadow root）
composedPath 获取事件完整路径
事件溯源与跨边界判断

答案

getRootNode() 返回节点所属的根（document 或 shadowRoot），得到 document 常用于判断节点是否在文档中、是否跨 shadow 边界；composedPath() 在事件监听中返回事件传播经过的完整节点路径，含 shadow 内部节点，用于判断事件来源与是否源自特定内部元素。工程实践：事件溯源时用 composedPath 判断点击是否落在组件内部某区域；用 getRootNode 判断节点所属根或跨树遍历；结合两者可实现跨边界的事件过滤与归属判断，是处理 Shadow DOM 事件与定位节点的常用工具。

解析

getRootNode 与 composedPath 解决"跨 Shadow 树定位节点/事件来源"的问题。getRootNode 面向静态归属，composedPath 面向事件路径，二者是事件溯源与跨树编程的基础 API。

示例代码

document.addEventListener('click', (e) => {
  const internal = e.composedPath().some(el => el?.matches?.('my-card'));
  const root = e.target.getRootNode();
  console.log(internal, root);
});

#

★★

13. Shadow DOM 的 Adopted Stylesheets（adoptedStyleSheets）在多实例样式复用的现代应用

问题

请说明 adoptedStyleSheets（Adopted Stylesheets）的机制，以及它在多实例样式复用中的现代应用？

考察点

adoptedStyleSheets 属性与 CSSStyleSheet 构造
多影子根共享样式表
性能与复用价值

答案

adoptedStyleSheets 是 ShadowRoot 与 Document 的属性，接受 CSSStyleSheet 数组，将样式表应用到该影子根/文档。通过 new CSSStyleSheet() 构造并 replaceSync 填充内容，同一份样式表可被多个 shadowRoot adopt，实现多实例共享样式，避免每实例重复解析与注入

解析

adoptedStyleSheets 是"样式共享"的现代手段，相比每个 shadowRoot 内嵌

示例代码

const sheet = new CSSStyleSheet();
sheet.replaceSync(':host{display:block}');
class X extends HTMLElement {
  connectedCallback() {
    this.attachShadow({ mode: 'open' }).adoptedStyleSheets = [sheet];
  }
}

#

★★

14. 可继承 CSS 属性穿过 Shadow 边界的规则，哪些属性（color、font、line-height）默认继承，:host 的 reset 与外部样式的协作边界？

问题

请说明可继承 CSS 属性穿过 Shadow 边界的规则，以及 :host 的 reset 与外部样式的协作边界？

考察点

可继承属性（color、font、line-height）跨边界继承
:host 的 reset 与继承控制
外部样式与内部继承的协作边界

答案

可继承的 CSS 属性（color、font-family、line-height、text-align 等）会沿 DOM 继承链穿过 Shadow 边界，从宿主作用于影子内部；而不可继承属性（margin、padding、background 等）不会穿透。因此组件内部默认会继承外部的字体与颜色，实现"与宿主一致"的内联感。:host 可用 reset 或显式继承来控制（如 :host { color: inherit; } 强制继承，或设置具体值屏蔽继承）。协作边界在于：外部主题通过继承属性与 CSS 变量影响组件，组件通过 :host 决定是否继承或重置，构成"外部可影响、组件可控制"的边界。工程上据此设计主题与组件默认样式平衡。

解析

理解"继承属性穿透、非继承不穿透"是样式协作边界的关键。:host 是控制继承与重置的开关，正确处理继承才能让组件既融入外部主题又保持自身默认样式。

示例代码

:host { color: inherit; font-family: inherit; } /* 显式继承 */
:host { color: #333; } /* 重置，屏蔽外部继承 */

#

★★

15. Shadow DOM（attachShadow、mode: open/closed）的样式与结构封装

问题

请说明 attachShadow 与 mode: open/closed 如何实现 Shadow DOM 的样式与结构封装？

考察点

attachShadow 创建影子根
样式隔离与结构封装
open/closed 对访问的影响

答案

attachShadow({ mode }) 在元素上创建影子根，将子内容安置到影子树中，实现两级封装：样式封装（影子内部样式不泄漏，外部样式不穿透，仅通过继承/变量/part 交互）与结构封装（宿主子元素与影子树并行，外部无法直接访问内部 DOM）。mode 决定封装强度：open 情况下 shadowRoot 可被外部访问，便于调试与测试；closed 情况下 shadowRoot 返回 null，外部不可直接访问，提供更强的封装。工程上 attachShadow 是自定义元素创建影子 DOM 的入口，样式封装让组件自包含，结构封装让内部实现可替换，mode 调整访问粒度。

解析

attachShadow 是 Web Components 样式与结构封装的基石。样式封装解决样式冲突，结构封装解决内部实现隔离，mode 决定外部可访问性，三者共同构成组件化封装模型。

示例代码

const root = this.attachShadow({ mode: 'open' });
root.innerHTML = `<style>:host{display:block}</style><div>内容</div>`;

#

★★

16. Shadow DOM 的内存占用与 SSR 序列化的边界

问题

请说明 Shadow DOM 的内存占用情况与 SSR 序列化的边界，以及工程上的考量？

考察点

Shadow DOM 的内存开销
大量实例的内存管理
SSR 序列化（DSD）与客户端升级的边界

答案

Shadow DOM 每个影子根、插槽、样式表都会带来一定内存开销，大量组件实例时累积明显。工程上需注意：adoptedStyleSheets 共享样式表可减少重复样式内存；避免在 shadow 内冗余嵌套；频率高、数量大的轻量组件可考虑不建 Shadow DOM（如用闭合元素）。SSR 序列化方面，Declarative Shadow DOM 允许服务端输出影子 DOM 到 HTML，但包含大量 shadow 结构会增加 HTML 体积；客户端需识别并升级，序列化边界在于"服务端输出结构、客户端接管逻辑"。工程上需权衡 Shadow 的封装收益与内存/序列化成本，在需要隔离的组件用 Shadow，简单复用场景可权衡。

解析

Shadow DOM 不是免费的，封装带来内存与序列化成本。合理使用共享样式、避免过度创建影子根，以及权衡 DSD 序列化体积，是规模化应用的性能考量。

#

★★

17. Shadow DOM 在样式隔离与微前端的工程价值

问题

请说明 Shadow DOM 在样式隔离与微前端架构中的工程价值？

考察点

样式隔离解决全局样式冲突
微前端中各应用样式隔离
Shadow DOM 在微前端中的适用与局限

答案

Shadow DOM 的样式隔离让组件样式自包含，不污染全局、不受全局影响，是样式隔离的基石。在微前端中，不同子应用常引入不同 UI 库与全局样式，容易互相覆盖；把子应用的内容挂载到 Shadow DOM 下，可隔离其样式，避免应用间样式冲突。工程价值：子应用自包含样式、可独立升级、不受宿主全局样式影响。但局限在于：Shadow DOM 隔离样式但不隔离 JS 全局（window、document）、事件与全局变量，且部分第三方库可能依赖全局样式或事件冒泡，需结合 iframe、作用域样式、CSS 变量等方案综合治理。工程上 Shadow DOM 常作为微前端样式隔离的补充而非唯一手段。

解析

微前端的核心挑战之一是样式隔离，Shadow DOM 提供天然隔离但只覆盖样式边界。理解其适用与局限，才能与 iframe、作用域 CSS 等方案正确组合，形成完整隔离策略。

#

★★

18. CSS Shadow Parts（::part()、::slotted()、exportparts）的样式穿透

问题

请说明 CSS Shadow Parts（::part、::slotted、exportparts）的样式穿透机制？

考察点

::part 选择内部命名部件
::slotted 选择插槽内容
exportparts 转发内部 part

答案

CSS Shadow Parts 提供受控的样式穿透接口：::part(name) 在外部选择组件内部标记了 part 属性的命名部件并覆盖样式；::slotted(selector) 在影子内部选择投射到插槽的 light DOM 内容；exportparts 允许组件把内部更深层部件的 part 名称转发给外部使用（如 exportparts="inner: outer"），使嵌套组件也能被外部定制。三者共同构成"封闭但有受控开口"的样式定制体系：外部可覆盖命名部件与插槽内容，但不能穿透到未声明的内部节点。工程价值在于组件库主题定制与用户定制边界的平衡，比无条件穿透更安全、更可控。

解析

CSS Shadow Parts 是样式定制接口的完整体系。::part 面向当前组件的内部部件，exportparts 负责嵌套转发，::slotted 面向插槽内容，理解三者组合可实现深层组件的受控定制。

示例代码

<!-- 组件内部 -->
<my-card part="card">
  <div part="header">...</div>
</my-card>

/* 外部 */
my-card::part(header) { background: #eee; }
/* 影子内部 */
::slotted(span) { color: blue; }

#

★

19. Shadow DOM 的 declarative Shadow DOM（）的工程价值

问题

请说明 declarative Shadow DOM（）的工程价值？

考察点

声明式创建影子 DOM
无需 JS 即可渲染
SSR 与 SEO、首屏性能

答案

Declarative Shadow DOM 通过 <template shadowrootmode="open"> 在 HTML 中声明影子根与内容，浏览器解析时自动创建 shadow root，无需客户端 JS 构造，也不依赖 attachShadow。工程价值：服务端可直接输出带 Shadow DOM 的 HTML，实现无需 JS 的首屏渲染，利于 SEO 索引与无 JS 环境可读；减少首屏对 JS 的依赖，配合 hydration 实现"先呈现、后增强"；降低客户端构造影子 DOM 的成本。局限是浏览器兼容性（需 polyfill 或在旧浏览器手动升级）。对 SSR 驱动的 Web Components 架构，DSD 是核心能力，让自定义元素完整支持服务端渲染。

解析

DSD 消除了"Shadow DOM 只能客户端创建"的瓶颈，使 Web Components 可完整 SSR。其价值在 SEO、首屏性能与渐进增强，是现代服务端渲染自定义元素的关键基础。

示例代码

<my-example>
  <template shadowrootmode="open">
    <style>:host{color:green}</style>
    <p>Hello</p>
  </template>
</my-example>

#

★

20. Shadow DOM 的 MutationObserver 跨边界（host vs shadow）

问题

请说明 Shadow DOM 中 MutationObserver 跨边界（host 与 shadow）的观察行为？

考察点

MutationObserver 观察范围
影子内部与宿主子树的观察差异
插槽与跨边界观察

答案

MutationObserver 默认观察指定节点及其子树（subtree），但 shadow root 是独立树，observer 不会自动跨入 Shadow 边界；要观察影子内部需在 shadowRoot 上单独建立 observer。反之，当宿主元素被插入/移除文档时，宿主上的 observer 会触发 childList 变化，但 shadow 内部的变化不会冒泡到宿主 observer。插槽相关内容（light DOM 节点投射）在 light DOM 中可被宿主 observer 观察到，但影子内部结构变化需在 shadowRoot 观察。工程上需在宿主与 shadowRoot 分别建立 observer 才能覆盖跨边界变化，或利用 slotchange 等事件感知插槽变化。

解析

MutationObserver 的"跨边界"是开发者常踩的坑：shadow 边界是观察的天然分界。理解宿主与 shadowRoot 各自需要 observer，才能正确监控组件内部与外部结构变化。

#

★

21. Shadow DOM 与 ARIA（无障碍）在跨树遍历的工程实践

问题

请说明 Shadow DOM 与 ARIA（无障碍）在跨树遍历中的工程实践？

考察点

无障碍树与 Shadow 树的关系
跨树名称计算与 ARIA 引用
可访问性工程实践

答案

无障碍树会遍历 Shadow DOM 边界，将影子内部的可访问节点与插槽内容纳入可访问性树，因此影子内部内容可被屏幕阅读器读取。跨树遍历的工程实践：跨边界 ARIA 引用（如 aria-labelledby 指向影子内部元素）受限制，需通过 idref 或 label 关联处理；组件需在宿主上设置正确 role 与 aria-* 属性，确保无障碍树语义正确；插槽内容在 light DOM 中，其可访问性归属由宿主承担。工程上需用正确角色、焦点管理与 aria 属性补齐可访问性，并测试屏幕阅读器对跨树内容的理解，避免因 Shadow 封装导致可访问性信息丢失。

解析

无障碍树跨 Shadow 边界遍历是 Web Components 可访问性的基础。理解"影子内部可访问、跨树 ARIA 引用受限"是工程实践的关键，需主动补齐角色与语义。

#

★

22. Shadow DOM 的 position: fixed 与浏览器渲染层的工程应用

问题

请说明 Shadow DOM 中 position: fixed 的行为特征及浏览器渲染层的工程应用？

考察点

position: fixed 的定位上下文
Shadow 边界对 fixed 的影响
弹层/浮层组件在 Shadow 中的实现

答案

position: fixed 通常相对于视口定位，但若祖先有 transform、filter、contain 等属性会改变定位上下文。在 Shadow DOM 中，fixed 元素仍相对视口，但当宿主或其祖先有 transform 等时，内外定位上下文一致，fixed 元素会相对该祖先而非视口。工程上，在 Shadow DOM 内实现弹层、tooltip、menu 等浮层组件时需注意：fixed 定位可能受宿主 transform 影响，导致弹层位置偏移；建议把浮层渲染到 body 或使用 popover 属性、Teleport 到顶层，或确保祖先无 transform。同时 Shadow 边界的渲染层与事件重定向需配合，确保浮层可点击与层级正确。

解析

fixed 定位在 Shadow 内与普通 DOM 行为一致，但受祖先 transform 影响，是弹层组件常见陷阱。理解定位上下文与渲染层，结合 popover/Teleport 方案可正确实现跨 Shadow 的浮层。