如何提升分组DataGrid性能？WPF GroupStyle引发性能异常排查

在WPF中使用DataGrid的GroupStyle时遇到性能问题：加载2500条数据本身、在CollectionView上配置GroupDescriptions或进行分组元素计算均无性能问题，但渲染环节表现极差。

经排查发现，仅在DataGrid中定义如下空GroupStyle时，数据加载耗时增至原来的10倍，RAM占用达原来的20倍，且无任何视觉变化（Grid为空）：

<DataGrid.GroupStyle>
    <GroupStyle>
        <GroupStyle.HeaderTemplate>
            <DataTemplate>
                <Grid>
                </Grid>
            </DataTemplate>
        </GroupStyle.HeaderTemplate>
    </GroupStyle>
</DataGrid.GroupStyle>

这显然不符合预期，请问此操作为何会导致DataGrid性能暴跌？

造成这种性能暴跌的核心原因在于WPF DataGrid启用GroupStyle时的内部渲染逻辑变化——哪怕HeaderTemplate是空的，也会触发完全不同的布局和虚拟化行为：

• 虚拟化机制失效
  默认状态下，DataGrid依赖行虚拟化（VirtualizingStackPanel）仅渲染可视区域内的数据行，大幅降低内存占用和渲染耗时。但一旦定义GroupStyle，DataGrid会自动切换到分组容器布局，此时默认的行虚拟化策略会被破坏：分组容器会强制加载所有分组头及其下的行，而非仅处理可视区域内的元素。2500条数据生成的大量分组容器实例，直接导致内存暴增、渲染耗时飙升。

• 分组容器的冗余开销
  即便HeaderTemplate是空Grid，WPF仍会为每个分组创建完整的GroupItem容器对象，包含绑定上下文、样式触发器、布局逻辑等额外资源。分组数量越多，生成的冗余容器就越多，每个容器都要占用内存并参与布局计算，叠加后引发性能雪崩。

• 嵌套布局的递归计算开销
  分组后的DataGrid布局变为嵌套结构：GroupItem包含分组头和子行容器，子行容器再包含数据行。这种嵌套结构会触发更多递归的测量与排列操作，哪怕分组头是空的，WPF仍会执行完整的布局流程，相比无分组时的扁平布局，计算量呈指数级增长。

简言之，只要定义了GroupStyle，无论模板内容是否为空，DataGrid都会切换到分组模式的渲染路径，放弃原本高效的行虚拟化，同时引入大量额外的容器和布局开销——这就是性能暴跌的根本原因。

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