简介
聊个小问题：在 Angular 开发中，你有没有遇到过那种“不得不用一个多余元素来包装一下”的尴尬场景？比如为了同时用上 *ngIf 和 *ngFor，硬生生套了一层无意义的 div，生成的 DOM 里全是冗余标签？
实际上，Angular 2+ 中提供了一个相当轻巧的解决方案 —— ng-container。它本身不会被渲染到 DOM 中，却可以作为结构指令的宿主，在不污染 DOM 结构的前提下优雅地解决这类问题。这篇文章就来拆解一下 ng-container 的几个典型场景。
先决条件
跟着本文走，你不需要太高的门槛，但最好能满足以下几点：
- 对 DOM 的结构和渲染有基本了解，这个比较容易 —— 如果不太熟悉，可以先翻翻《理解 DOM》系列教程。
- 对 Angular 模板和结构指令（比如
*ngIf、*ngFor）有初步认识会更好，能帮你更快地跟上节奏。
用 ng-container 减少冗余元素
在 Angular 模板中，一个元素上不能同时使用多个结构指令。比如下面这段代码是编译不过的：
[secondary_label 无效示例]{{ todo.content }}
一编译，控制台就会抛出一个错误：
[secondary_label 无效示例输出]
无法在一个元素上有多个模板绑定。只能使用一个带 * 前缀的属性
常见的绕路方法是再套一层 div 来分开绑定：
[secondary_label 有效示例]
{{ todo.content }}
但是你看，这就在 DOM 里硬生生插进了一个多余的 div 容器：
[secondary_label 有效示例输出]
待办事项内容 1
待办事项内容 2
待办事项内容 3
这时候 ng-container 就派上用场了。它只充当逻辑上的宿主，不会在 DOM 里留下任何痕迹。同样的功能，用 ng-container 改写一下：
[secondary_label 改进后的有效示例]{{ todo.content }}
渲染出来的 DOM 干净利落：
[secondary_label 改进后的示例输出]待办事项内容 1
待办事项内容 2
待办事项内容 3
类似地，还有一种常见场景 —— 根据条件来内联一段文本，通常会用 span 来配合 ngIf：
[secondary_label 示例]糟糕： {{ message }}
如果 error 为真，渲染结果中就会多一个无意义的 span 包裹器：
[secondary_label 示例输出]糟糕： 发生了一个错误。
换成 ng-container：
[secondary_label 改进后的示例]
糟糕： {{ message }}
输出就变成了：
[secondary_label 改进后的示例输出]糟糕：发生了一个错误。
少了无谓的标签层级，DOM 树自然更精简，对 CSS 选择器的副作用也控制得更干净。这不是什么炫技，就是日常编码中非常实用的一个小技巧。
用 ng-container 保证 HTML 结构的合法性
很多 HTML 标签对子元素有严格的约束，比如 ul 里只能放 li，不能直接套 div。一旦结构不合法，虽然浏览器会尽量容错，但测试、可访问性、跨设备兼容性等方面都可能埋下隐患。
举个例子，下面的写法看起来没什么问题，但已经破坏了 HTML 的语义规范：
[secondary_label 无效示例]
- {{ todo.content }}
直接用 ng-container 替换掉那个 div，既保留了 *ngFor 的逻辑，又确保了 li 是 ul 的直接子元素：
[secondary_label 有效示例]
- {{ todo.content }}
这个改动很小，但带来的效果很实在 —— 代码更健壮，也更符合标准。
结论
从本文的几个例子可以看出，ng-container 主要解决两个痛点：一是避免 DOM 中产生多余的包裹元素，减少冗余；二是在需要满足严格 HTML 结构约束的场景下，提供一个不会干扰 DOM 的合法宿主。它本身不是炫技，而是 Angular 模板设计中一个非常务实的基础工具。
