为什么Angular中子组件直接用*ngFor在Chrome DevTools中更卡顿？

这个现象是Chrome DevTools 元素检查模块的性能特性和两种写法生成的DOM层级结构差异共同导致的，和Angular框架本身的运行性能无关。

两种写法的DOM结构差异 #

• 第一种写法（*ngFor直接挂载在<app-item>上）生成的DOM结构：

  <app-list>
    <app-item data="0"></app-item>
    <app-item data="1"></app-item>
    <!-- 共1000个同级的<app-item>直接作为<app-list>的子节点 -->
    <app-item data="999"></app-item>
  </app-list>
  

• 第二种写法（*ngFor挂载在<div>上，内部包裹<app-item>）生成的DOM结构：

  <app-list>
    <div>
      <app-item data="0"></app-item>
    </div>
    <div>
      <app-item data="1"></app-item>
    </div>
    <!-- 共1000个同级的<div>作为<app-list>的子节点，每个<div>下只有1个<app-item> -->
    <div>
      <app-item data="999"></app-item>
    </div>
  </app-list>
  

卡顿触发的具体逻辑 #

Chrome DevTools的元素选择、高亮、节点信息计算逻辑，会对当前选中元素的所有同级兄弟节点做大量遍历计算：

1. 匹配当前元素对应的CSS选择器（需要计算元素在同级节点中的索引，生成类似app-item:nth-child(500)的选择器）
2. 计算元素盒模型、位置尺寸时，需要比对相邻同级元素的布局信息
3. 更新Elements面板的节点树视图、面包屑导航时，需要遍历同级节点更新展示状态

第一种写法中，你选中的<app-item>有999个同级兄弟节点，DevTools单次选中操作需要遍历计算1000个节点的相关信息，计算量非常大，就会触发明显卡顿。
第二种写法中，你选中的<app-item>没有任何同级兄弟节点（每个<div>下只有它一个子元素），DevTools单次选中操作只需要计算当前节点和它的父<div>节点，计算量大幅降低，卡顿就会明显减轻。

补充说明 #

正常使用页面（不打开DevTools元素检查功能）时，两种写法的运行性能差异可以忽略，这个卡顿问题只在使用Chrome DevTools元素检查功能时会触发。

内容的提问来源于stack exchange，提问作者Sylvaner