Angular 组件样式与视图封装机制：从 Emulated 到 ShadowDom 的源码级实战指南

本篇技术指南围绕 Angular 官方文档《Styling components》（原文档）展开，系统讲解组件中 CSS 样式的两种书写方式、四种视图封装（view encapsulation）模式的适用场景，并结合 Angular 仓库中的编译器源码（shadow_css.ts）、核心元数据定义（view.ts）与 DOM 渲染器实现（dom_renderer.ts），还原“选择器在编译期如何被改写”的完整机制，帮助读者在组件库开发、样式隔离与第三方库定制之间做出正确的封装模式选择。

组件样式的两种声明方式

组件可以（可选地）包含应用于其 DOM 的 CSS 样式。Angular 提供两种声明位置：

方式一：内联 styles 数组。样式直接写在 @Component 装饰器中，适合小体量、单文件组件：

import {Component} from '@angular/core';

@Component({
  selector: 'profile-photo',
  template: `<img src="profile-photo.jpg" alt="Your profile photo" />`,
  styles: `
    img {
      border-radius: 50%;
    }
  `,
})
export class ProfilePhoto {}

方式二：独立样式文件 styleUrl。样式与模板分离，适合样式较多或团队协作场景：

import {Component} from '@angular/core';

@Component({
  selector: 'profile-photo',
  templateUrl: 'profile-photo.html',
  styleUrl: 'profile-photo.css',
})
export class ProfilePhoto {}

样式参与 JavaScript 模块系统

当 Angular 编译组件时，这些样式会随组件的 JavaScript 产物一起输出（emit），意味着组件样式参与 JavaScript 模块系统。实际效果是：当渲染一个 Angular 组件时，框架会自动加载其关联样式，即使该组件是懒加载的——样式不会遗漏，因为它们是模块加载链的一部分。

这也解释了为什么样式随路由懒加载：路由对应的懒加载 chunk 里同时包含模板、指令与样式，模块被 import 时样式即刻生效，无需额外的 <link> 注入时机管理。

与任意 CSS 预处理工具链协作

Angular 本身只消费“编译产物 CSS”，因此它可以与任何能输出 CSS 的工具链配合，包括 Sass、Less 和 Stylus。从源码结构看，Angular 编译器接收到的已经是文本形式的 CSS 字符串（由 Angular CLI 的构建管线在编译前完成预处理），因此只要你的构建工具能产出 CSS，就可以无缝接入 Angular 的样式封装流程。

视图封装（View Encapsulation）四种模式

每个组件都有一个 view encapsulation 设置，决定框架如何为组件样式划定作用域。ViewEncapsulation 枚举共定义了四种模式，其枚举值与官方文档注释可在 packages/core/src/metadata/view.ts 中确认：

模式	枚举值	作用域行为	备注
Emulated	0	通过属性选择器模拟 Shadow DOM 隔离	默认模式
None	2	不封装，组件样式等同全局样式
ShadowDom	3	使用浏览器原生 Shadow DOM API	有事件、<slot> 等副作用
ExperimentalIsolatedShadowDom	4	严格的双向隔离	@experimental 21.0

在 @Component 装饰器中指定封装模式：

import {Component, ViewEncapsulation} from '@angular/core';

@Component({
  selector: 'profile-photo',
  template: `<img src="profile-photo.jpg" alt="Your profile photo" />`,
  encapsulation: ViewEncapsulation.None,
})
export class ProfilePhoto {}

在 AOT 编译链中，encapsulation 字段由 ngtsc 注解处理器解析为枚举数值并写入组件元数据（参见 handler.ts），运行时渲染器据此选择对应的 Renderer2 实现。

ViewEncapsulation.Emulated：默认模式及其编译期选择器改写

默认情况下，Angular 使用仿真（emulated）封装，使组件样式只作用于该组件模板中定义的元素。此模式下，框架会：

1. 为每个组件生成一个唯一的 HTML 属性（形如 _ngcontent-abc123）；
2. 将该属性添加到组件模板内的元素上；
3. 把该属性选择器插入组件样式中的 CSS 选择器。

例如组件中的 img { border-radius: 50%; } 最终会改写为 img[_ngcontent-abc123]，从而保证组件样式不外泄、不影响其他组件。但要注意：组件外定义的全局样式仍然可以影响仿真封装组件内部的元素——仿真封装只拦截“向外泄漏”，不拦截“向内渗透”。

编译期改写机制：ShadowCss 源码解析

这套选择器改写由编译器中的 ShadowCss 类完成（shadow_css.ts）。类头注释明确说明它源自 webcomponents.js 中 ShadowCSS 的移植，并按 Angular 需求演化。核心入口是 shimCssText(cssText, selector, hostSelector)：

• selector：附加到 host 内部所有元素的属性选择器；
• hostSelector：仅附加到 host 元素本身的属性选择器。

该改写发生在编译期，由 render3/view/compiler.ts 中的 compileStyles 调用；对外还导出了 encapsulateStyle 函数，允许第三方用同一套规则封装样式表。ShadowCss 的单元测试（如 shadow_css 测试目录 下的 host_and_host_context_spec.ts、nesting_spec.ts）覆盖了 :host、:host-context 与嵌套选择器的各种边界情况。

改写过程分三步（见 _scopeCssText）：

1. 替换伪类占位符：将 :host 与 :host-context 分别替换为内部标记 -shadowcsshost / -shadowcsscontext；
2. 转换 :host：如 :host(.foo) > .bar 改写为 .foo<scope> > .bar；
3. 转换 :host-context 并加作用域：@keyframes 名称也会被加上作用域前缀，防止全局动画名冲突（见 _scopeKeyframesRelatedCss 注释中的示例：box-animation → scopeName_box-animation，而引用到外部定义 keyframes 的 animation 规则则保持不动）。

:host 与 :host-context() 的完整支持

仿真模式下，Angular 支持 :host 伪类；同时尽管 :host-context() 在现代浏览器中已被弃用，Angular 编译器仍为其提供完整支持。两者都可以不依赖原生 Shadow DOM 使用——因为在编译期，这些伪类被转换成属性选择器，运行时并不遵循这些原生伪类的规则（浏览器兼容性、特异性等）。

源码层面的证据：

• :host(.foo) > .bar 由 _convertColonHost 改写，注释示例为 :host(.foo) > .bar → .foo<scopeName> > .bar；
• :host-context(.foo) > .bar 由 _convertColonHostContext 改写为 .foo<scopeName> > .bar, .foo <scopeName> > .bar 这样的双选择器，覆盖“祖先匹配”与“自身匹配”两种情况；多个上下文选择器时，_combineHostContextSelectors 会生成所有祖先/自身/同层组合；
• 需要特别说明：仿真模式不支持其他与 Shadow DOM 相关的伪类，如 ::shadow 或 ::part。

::ng-deep：受强烈不推荐使用的穿透选择器

仿真模式支持一个自定义伪类 ::ng-deep。Angular 团队强烈不推荐新代码使用 ::ng-deep，该 API 仅为向后兼容而保留。

从源码看，::ng-deep 及其历史写法 /deep/、>>> 都被同一个正则识别为“deep 选择器”（shadow_css.ts#L1012-L1015），注释明确说明 deep combinator 已在 CSS 规范中弃用，相关支持未来会移除。

当选择器中出现 ::ng-deep 时，Angular 在该点之后停止应用视图封装边界，其后任何部分都可以匹配组件模板之外的元素。原文档给出的四个典型案例：

1. p a（普通仿真封装）：匹配组件自己模板内、<p> 的子孙 <a>；
2. ::ng-deep p a：匹配整个应用任意位置中 <p> 的子孙 <a>——等效于一条全局样式；
3. p ::ng-deep a：要求 <p> 必须来自组件自身模板，但 <a> 可以在应用任意位置——因此它既可以在组件模板内，也可以在投影内容或子组件视图中；
4. :host ::ng-deep p a：<a> 和 <p> 都必须是组件 host 元素的子孙，可来自组件模板或子组件视图，但不会延伸到 host 之外。

源码实现上，_scopeSelector 会把选择器按 deep 标记拆分：deep 之前的“浅层部分”照常加作用域属性，deep 之后的部分原样保留、不加属性选择器，从而精确实现了上述四种语义差异。

实践建议：需要穿透封装时，优先考虑 :host ::ng-deep（把穿透范围限制在 host 内）或直接使用 ViewEncapsulation.None，尽量避免裸 ::ng-deep 造成的全局污染。

ViewEncapsulation.ShadowDom：原生 Shadow DOM 封装

ShadowDom 模式使用 Web 标准的 Shadow DOM API 为组件划定样式边界。启用后，Angular 向组件 host 元素挂载 shadow root，将组件模板与样式渲染到对应的 shadow 树中；shadow 树内的样式无法影响树外元素。

运行时实现与关键副作用

在 dom_renderer.ts 中，createRenderer 根据 encapsulation 分支创建不同的渲染器：ShadowDom 模式返回 ShadowDomRenderer。该渲染器在初始化时调用 (hostEl).attachShadow({mode: 'open'})（dom_renderer.ts#L573），并把组件样式以 <style> 元素追加进 shadow root（#L599），外部 <link> 引用的样式也会被移入 shadow root（#L615）。

需要特别注意的是，开启 ShadowDom 封装的影响远不止样式作用域。文档明确提示：在 shadow 树中渲染组件会改变事件传播（事件不再跨越 shadow 边界向外冒泡到 document）、与 <slot> 内容投影 API 的交互方式，以及浏览器开发者工具的元素呈现方式。在应用中启用该选项前，务必完整理解 Shadow DOM 的所有影响。

一个与 SSR 相关的重要细节：在服务端渲染（Domino 环境）中，由于 Domino 不支持 Shadow DOM，createRenderer 会把 ShadowDom / ExperimentalIsolatedShadowDom 封装强制降级为 Emulated，以保证服务端与客户端行为一致。相关行为有测试覆盖（dom_renderer_spec.ts）。

ViewEncapsulation.ExperimentalIsolatedShadowDom：严格双向隔离

该模式的行为与 ShadowDom 相同，但严格保证只有该组件自己的样式会作用于模板内元素：全局样式无法影响 shadow 树中的元素，shadow 树内的样式也无法影响树外元素，实现完全的双向隔离。

源码证据有两处：

• view.ts#L47-L54 中的枚举注释将其标记为 @experimental 21.0；
• 在 dom_renderer.ts 中，ShadowDomRenderer 的 sharedStylesHost 是可选注入——注释明确写道“This is optional as it is not used by ExperimentalIsolatedShadowDom”。从源码结构看，普通 ShadowDom 模式会把共享样式挂载点接入 shadow root，而隔离模式跳过该步骤，这正是“全局样式无法渗入”的实现基础。

ViewEncapsulation.None：关闭封装，样式等同全局

该模式禁用组件的所有样式封装，组件关联的任何样式都按全局样式行为生效。运行时对应 dom_renderer.ts 中的 NoneEncapsulationDomRenderer，创建渲染器时直接调用 applyStyles() 将样式注入文档，而非像仿真模式那样通过 applyToHost 给 host 加属性标记。典型用途：需要全局生效的工具型组件（如全局 Toast 样式），或希望与第三方 CSS 库规则精确对齐的场景。

NOTE：在 Emulated 和 ShadowDom 模式下，Angular 并不 100% 保证组件样式总是压过来自外部的样式。冲突时，应假定外部样式与组件样式具有相同特异性（specificity），最终结果取决于 CSS 层叠的常规规则（顺序等）。

在模板中定义样式：<style> 元素

组件模板可以直接使用 <style> 元素定义附加样式，组件的视图封装模式同样适用于这类样式（仿真模式下会被加上作用域属性）。但有一个硬限制：Angular 不支持在 <style> 元素内部使用模板绑定——<style> 内容是静态字符串，无法通过插值或 [ngStyle] 类绑定动态改写。

引用外部样式文件：<link> 与 @import

组件模板中可以使用 <link> 元素引用 CSS 文件，CSS 中也可使用 @import at-rule 引用其他 CSS 文件。Angular 将这些引用视为外部样式（external styles），关键结论是：外部样式不受仿真视图封装影响——它们不会被加上组件作用域属性，因此在仿真模式下这些被引用的规则会保持原样匹配，需要开发者自行注意选择器特异性带来的交叉影响。

从实现层面看，ShadowDom 模式下渲染器会把模板中的 <link> 元素移入 shadow root（dom_renderer.ts#L615），使外部样式同样被限制在 shadow 边界内；而仿真模式仅处理组件自有样式文本，<link> 指向的外部规则则原样保留在文档中。

封装模式选型速查

结合原文档结论与仓库源码，给出工程选型参考：

场景	推荐模式	依据
普通应用组件（默认选择）	Emulated	零外部行为副作用，样式随 JS 模块懒加载，默认值 0（view.ts）
需要与外部全局样式彻底双向隔离的组件库	ExperimentalIsolatedShadowDom	跳过 sharedStylesHost，严格隔离；接受实验性 API 风险
构建 Web Components 语义、需要原生事件/<slot> 行为	ShadowDom	原生 shadow tree，但需接受事件传播与 DevTools 变化
样式本身就是全局工具样式（如 reset、主题变量）	None	渲染器直接 applyStyles() 注入文档

小结

• 组件样式可内联（styles）或外链（styleUrl），编译后随 JS 模块一起输出，天然适配懒加载；
• 四种封装模式的枚举值与语义定义于 packages/core/src/metadata/view.ts；
• Emulated 是默认模式：仿真属性选择器改写由 ShadowCss 在编译期完成，完整支持 :host 与 :host-context()，::ng-deep 仅为向后兼容保留且被官方强烈不推荐；
• ShadowDom 通过 attachShadow 实现原生隔离，但会改变事件传播、<slot> 交互与 DevTools 呈现，且 SSR 环境会降级为 Emulated；
• ExperimentalIsolatedShadowDom（21.0 实验特性）额外阻断全局样式渗入；None 则让组件样式成为全局样式；
• 模板 <style> 支持封装但不支持内部绑定；<link>/@import 引用的是外部样式，不受仿真封装改写。

以上内容均以当前仓库源码与 官方样式指南 为准，若升级到新的 Angular 版本，建议重新核对 ExperimentalIsolatedShadowDom 的实验状态标注与 ::ng-deep 的弃用时间表。