本文讲解如何在 Angular 模板中避免因嵌套 *ngFor 导致的 rowspan 内容重复渲染问题，核心是重构数据结构以匹配表格行合并逻辑，而非依赖条件渲染或 trackBy 技巧。
本文讲解如何在 angular 模板中避免因嵌套 *ngfor 导致的 `rowspan` 内容重复渲染问题，核心是重构数据结构以匹配表格行合并逻辑，而非依赖条件渲染或 trackby 技巧。
在使用 Angular 构建多层嵌套表格（如“主件—批次（rafale）—子件”结构）时，一个常见陷阱是：*将需跨行显示的父级数据（如 partQty 和 rowspan）保留在外层对象中，却在内层 `ngFor中反复访问它**。这会导致同一数值被多次渲染——正如你在示例中观察到的：refRaw.partQty在refRaw.rafale的每次迭代中都被重复输出，破坏了rowspan` 的语义与视觉效果。
根本原因在于：HTML 表格的 rowspan 属性仅控制单元格纵向跨越的行数，但不会自动阻止该单元格内容在后续 <tr> 中被再次插入。Angular 的 *ngFor 是纯模板指令，它不感知 DOM 渲染上下文或已渲染状态；试图用 *ngIf “跳过已遍历项”不仅逻辑复杂、易出错，更违背响应式设计原则——模板应声明“什么要渲染”，而非“什么时候不渲染”。
✅ 正确解法：让数据结构对齐 UI 结构
将原本属于 refRaw（父级物料）的 partQty 和 rowspan 下沉至每个 rafale 项中。只有真正需要展示该数量的 rafale 才携带该字段；其余同组 rafale 项则留空或省略。这样，模板可直接绑定，无需条件判断：
<tbody class="table-group-divider">
<ng-container *ngFor="let refRaw of tableMongoData">
<tr *ngFor="let rafale of refRaw.rafale">
<th class="text-center" scope="row">{{ rafale.name }}</th>
<!-- 仅当 rafale 自带 partQty 时才渲染，并应用其 rowspan -->
<td
*ngIf="rafale.partQty"
[attr.rowspan]="rafale.rowspan"
class="text-center align-middle"
tabindex="0"
data-html="true"
data-bs-toggle="tooltip"
data-bs-placement="top"
data-bs-title="Referência: "
>
{{ rafale.partQty }}
</td>
<!-- 其余列（PB/PN/PA）保持不变 -->
<td class="text-center">{{ rafale.refs.find(r => r.type === 'PB')?.partQty }}</td>
<td class="text-center">{{ rafale.refs.find(r => r.type === 'PN')?.partQty }}</td>
<td class="text-center">{{ rafale.refs.find(r => r.type === 'PA')?.partQty }}</td>
</tr>
</ng-container>
</tbody>对应的数据结构调整如下（关键变化已加粗）：
tableMongoData = [
{
ref: '322416730R',
type: 'RAW',
rafale: [
{
name: '14x63',
**partQty: '1.467', // ← 下沉至此
**rowspan: 2, // ← 下沉至此**
refs: [ /* ... */ ]
},
{
name: '14x69',
// ← 无 partQty & rowspan，此行不渲染左侧数量列
refs: [ /* ... */ ]
}
]
},
// ...
];⚠️ 注意事项：
- *不要滥用 `ngIf+ 状态标记**：例如在组件类中维护renderedRefs: Set
并在模板中*ngIf="!renderedRefs.has(refRaw.ref)"` —— 这会耦合模板与状态管理，破坏可预测性，且在变更检测中易引发异常。 - trackBy 不解决此问题：trackBy 仅优化 DOM 复用性能，不影响渲染逻辑或内容重复。
- 服务端预处理更优：若数据来自 API，建议在 service 层完成 partQty 的下推逻辑（如 mapRafaleWithParentQty()），而非在模板或组件中做运行时判断。
- CSS 替代方案慎用：虽可用 visibility: hidden 或 display: none 隐藏重复单元格，但这违反语义化 HTML 原则，影响可访问性（screen reader）及打印样式。
总结：Angular 模板的本质是数据驱动的声明式视图。当渲染逻辑变得“需要记忆历史”或“依赖执行顺序”时，往往意味着数据模型与 UI 需求存在错位。优先重构数据（denormalize for view），远胜于在模板中编写防御性逻辑。此举不仅修复 rowspan 问题，更提升代码可读性、可测试性与长期可维护性。
