1. 从“行号消失”说起：WPF DataGrid 序列号到底难在哪

做过 WPF 桌面端表格开发的人，大概率都遇到过这样一个场景：数据加载完了，界面也渲染出来了，但用户第一眼就问——“这行号呢？我怎么知道现在看的是第几条？”尤其是做数据核对、财务对账、日志排查这类场景，行号几乎是刚需。可 WPF 自带的DataGrid偏偏不给你现成的行号列，它只提供数据行的展示，不负责“编号”这件事。

这就是“WPF DataGrid 序列号”这个看似简单、实则暗藏玄机的需求。表面上看，无非就是在每行前面加一个 1、2、3、4 的数字。但真正动过手的人都知道，这里面至少有三层坑：第一层是怎么显示，第二层是排序、删除、过滤之后编号怎么保持正确，第三层是虚拟化开启时编号会不会错乱。很多人第一次写，直接在数据模型里加一个Index属性，绑定上去，跑起来看着没问题，结果一排序就露馅了——编号跟着数据行一起被搬走了，原本第 1 行变成了第 5 行，用户直接懵了。

所以这篇内容，我想从一个一线开发者的角度，把 WPF DataGrid 序列号这件事彻底讲透。不管你是刚接触 WPF 的新手，还是已经写过几年桌面端、但一直用“土办法”凑合的老手，都能从里面找到能直接抄作业的方案。我会把几种主流实现方式的原理、适用场景、性能差异、以及实测中踩过的坑，一条一条摊开讲。核心关键词就一个：WPF DataGrid 序列号，围绕它展开的所有细节，我都会尽量补全。

先说结论，省得你着急：最稳、最推荐的做法，是用DataGrid的LoadingRow事件配合GetRow来动态设置行头，而不是在数据模型里塞索引字段。为什么？往下看。

2. 三种主流实现路径的底层逻辑与取舍

在动手之前，先把可选方案理清楚。WPF DataGrid 加序列号，市面上流传的做法大致归为三类，每一类背后对应的是不同的设计思路，也决定了它能不能扛住排序、过滤、虚拟化这些真实业务场景。

2.1 方案一：在数据模型里加索引属性

这是最直觉的做法。定义一个Student或Order类，里面加一个int Index属性，绑定到 DataGrid 的第一列。数据加载时，用for循环给每一行的Index赋值。

public class OrderItem { public int Index { get; set; } public string OrderNo { get; set; } public decimal Amount { get; set; } } // 加载时 var list = GetOrders(); for (int i = 0; i < list.Count; i++) { list[i].Index = i + 1; } dataGrid.ItemsSource = list;

这个方案的好处是简单直接，XAML 里写个Binding Index就完事。但它的致命伤在于：索引是数据的一部分，会跟着数据一起被排序、过滤、移动。用户点一下“金额”列排序，Index不会重新计算，于是你看到的就是 3、1、5、2 这种乱序编号。如果业务允许排序，这个方案基本就废了。

注意：如果你的表格是只读的、永远不排序、不分页、不删除，那这个方案能用。但只要有一项不满足，就别选它。

2.2 方案二：用 Converter 转换 ItemsControl.AlternationIndex

WPF 的ItemsControl有一个附加属性叫AlternationIndex，配合AlternationCount使用，本来是用来做隔行换色的。有人发现它可以拿来当行号，写一个IValueConverter，把AlternationIndex加 1 转成字符串。

<DataGrid AlternationCount="1000000"> <DataGrid.Columns> <DataGridTextColumn Header="序号" Binding="{Binding RelativeSource={RelativeSource AncestorType=DataGridRow}, Path=(ItemsControl.AlternationIndex), Converter={StaticResource IndexConverter}}" /> </DataGrid.Columns> </DataGrid>

这个方案比方案一优雅，因为它不污染数据模型，编号是“视图层”的东西。但它有个隐藏问题：AlternationIndex在虚拟化开启时，只对已经生成容器的行有效，滚动到没渲染过的区域，编号可能不连续。而且AlternationCount要设得足够大，否则会循环。实测下来，在数据量超过几百行、开启虚拟化的情况下，这个方案会出现编号跳变，不太可靠。

2.3 方案三：LoadingRow 事件动态设置行头

这是我最推荐的方案。思路是：不碰数据模型，也不依赖 AlternationIndex，而是在每一行被加载（容器生成）的时候，通过DataGridRow拿到它在Items中的真实索引，然后设置Header。

private void DataGrid_LoadingRow(object sender, DataGridRowEventArgs e) { e.Row.Header = (e.Row.GetIndex() + 1).ToString(); }

GetIndex()是DataGridRow的扩展方法，返回该行在DataGrid.Items中的索引。这个索引是视图层实时计算的，排序、过滤之后，Items的顺序变了，GetIndex()返回的值也跟着变，所以编号永远和当前显示顺序一致。

XAML 里只需要把行头宽度打开：

<DataGrid LoadingRow="DataGrid_LoadingRow" HeadersVisibility="Row" RowHeaderWidth="50"> </DataGrid>

三种方案的对比，我整理成一张表，方便你按场景选：

选型逻辑其实就一句话：编号是视图的属性，不是数据的属性，所以应该由视图层来负责。方案三正好符合这个原则，所以它是首选。

3. LoadingRow 方案的完整落地步骤

确定了方案三，接下来把它跑通。这一节我把从零到能用的完整步骤写清楚，包括 XAML、后台代码、以及几个容易忽略的配置项。

3.1 XAML 侧的关键配置

先看 DataGrid 的声明。除了绑定ItemsSource和加LoadingRow事件，有两个属性必须显式设置，否则行头根本不显示：

<DataGrid x:Name="MainGrid" AutoGenerateColumns="False" CanUserAddRows="False" HeadersVisibility="Row" RowHeaderWidth="60" LoadingRow="MainGrid_LoadingRow"> <DataGrid.Columns> <DataGridTextColumn Header="订单号" Binding="{Binding OrderNo}" Width="150"/> <DataGridTextColumn Header="客户" Binding="{Binding Customer}" Width="120"/> <DataGridTextColumn Header="金额" Binding="{Binding Amount}" Width="100"/> </DataGrid.Columns> </DataGrid>

HeadersVisibility="Row"是核心，它告诉 DataGrid 要显示行头区域。默认值是Column，也就是只显示列头，行头是隐藏的。很多人写完LoadingRow发现没效果，八成就是漏了这个属性。

RowHeaderWidth建议给个固定值，比如 50 到 60。如果不设，行头宽度可能为 0，或者被内容撑得忽宽忽窄，视觉上很难看。

CanUserAddRows="False"也建议加上。因为 DataGrid 默认允许用户在最后一行输入新数据，那一行的行头会显示成一个星号*，和我们的数字编号混在一起很违和。关掉它，编号就干净了。

3.2 后台事件处理与 GetIndex 的细节

后台代码就一行核心逻辑，但有几个细节值得说：

private void MainGrid_LoadingRow(object sender, DataGridRowEventArgs e) { // GetIndex 返回的是行在 Items 集合中的从 0 开始的索引 int displayIndex = e.Row.GetIndex() + 1; e.Row.Header = displayIndex.ToString(); }

GetIndex()这个方法在System.Windows.Controls命名空间下，是DataGridRow的扩展方法，不需要额外引用。它内部实际上是通过ItemContainerGenerator.IndexFromContainer来算的，所以拿到的是当前视图顺序下的索引，这正是我们想要的。

有一点要注意：LoadingRow在行容器被重新生成时都会触发。比如排序、过滤、滚动虚拟化回收再生成，都会重新走一遍。所以编号会自动刷新，不需要你手动干预。这也是它比方案一强的地方。

3.3 行头样式微调

默认的行头样式比较朴素，数字靠左或者垂直居中不好看。可以加一段样式，让数字居中、加个浅灰背景：

<DataGrid.RowHeaderStyle> <Style TargetType="DataGridRowHeader"> <Setter Property="HorizontalContentAlignment" Value="Center"/> <Setter Property="VerticalContentAlignment" Value="Center"/> <Setter Property="Background" Value="#F5F5F5"/> <Setter Property="FontWeight" Value="SemiBold"/> </Style> </DataGrid.RowHeaderStyle>

这样行号看起来就像一个正经的序号列了。如果你希望行头和普通列一样有边框，可以再补一个BorderBrush和BorderThickness，不过默认样式通常已经带了分隔线，看个人审美。

4. 排序、过滤、删除场景下的编号行为实测

方案三在静态数据下没问题，但真实业务里，用户会排序、会过滤、会删行。这一节我用实测的方式，把每种操作下编号的表现说清楚，顺便把可能出问题的地方标出来。

4.1 点击列头排序后的编号刷新

假设原始数据是 5 条订单，编号 1 到 5。用户点击“金额”列排序，DataGrid 会重新排列Items的顺序。这时候LoadingRow会不会重新触发？

实测结果是：会。排序操作会导致行容器重新生成，LoadingRow被再次调用，GetIndex()返回新的位置，行头数字随之更新。你看到的就是排序后从 1 开始重新编号，完全符合直觉。

但这里有个前提：你的ItemsSource必须是支持排序的集合，比如List<T>配合 DataGrid 内置排序，或者CollectionViewSource。如果你用的是ObservableCollection并且自己写了排序逻辑，只要集合顺序变了，LoadingRow同样会触发。

4.2 过滤后编号是否连续

过滤场景稍微复杂一点。假设你用CollectionViewSource的Filter事件过滤掉了一部分数据，DataGrid 只显示符合条件的行。这时候GetIndex()返回的是过滤后视图中的索引，所以编号会从 1 连续排到 N，不会出现“跳号”。

这正是我们想要的。如果编号是数据模型里的固定值，过滤后就会出现 2、5、7 这种断号，用户看着别扭。而GetIndex()天然解决了这个问题。

4.3 删除行之后的编号重排

删除行的情况要分两种。第一种是用户通过 DataGrid 的删除键删行，第二种是后台代码从ItemsSource里移除数据。

无论哪种，只要Items集合发生了变化，DataGrid 都会重新生成受影响的容器，LoadingRow触发，编号重排。实测下来，删除中间某行后，后面的行号会自动往前补，不会留空。

提示：如果你在删除时遇到编号没刷新，先检查是不是用了ItemsSource的直接赋值而不是可观察集合。直接赋值整个新列表，DataGrid 会重建所有行，编号肯定刷新；但如果集合本身不通知变更，界面可能不更新。

4.4 虚拟化开启时滚动到远处的编号表现

这是方案三最容易被质疑的点。DataGrid 默认开启行虚拟化（EnableRowVirtualization="True"），意味着只有可视区域附近的行容器会被生成，滚出视野的行容器会被回收。

那滚动到第 500 行时，编号还是对的吗？实测结论：对的。因为LoadingRow在容器被重新生成时触发，GetIndex()根据当前容器对应的数据项在Items中的位置计算，所以即使容器是复用的，索引也是准的。

不过有一个边界情况：如果你在LoadingRow里做了耗时操作，比如查数据库、算复杂公式，快速滚动时会明显卡顿。所以事件处理里尽量只做赋值，别塞重逻辑。

5. 那些年我踩过的坑与排查链路

这一节是整篇内容里最“值钱”的部分。网上讲 WPF DataGrid 序列号的文章不少，但大多只给代码，不讲踩坑。我把实际项目中遇到的几个典型问题，连同排查过程一起写出来，你遇到类似现象时可以照着查。

5.1 行头死活不显示：HeadersVisibility 的默认值陷阱

第一次做这个需求时，我写完LoadingRow，运行，行头区域一片空白。调试发现e.Row.Header确实被赋值了，但界面上就是看不到。

排查链路是这样的：先确认LoadingRow有没有触发——加断点，触发了。再看e.Row.Header的值——是 “1”。那问题只能出在显示层。翻文档才发现，DataGrid.HeadersVisibility的默认值是Column，也就是只显示列头。行头虽然被赋值了，但整个行头区域是隐藏的，自然看不到。

改成HeadersVisibility="Row"或者All之后，行号立刻出现。这个坑的隐蔽性在于：代码逻辑完全正确，问题出在一个你根本没注意的默认属性上。

5.2 排序后编号错乱：误用了 ItemIndex 而非 GetIndex

有一次在旧项目里改代码，发现排序后编号乱了。查了半天，发现前任开发者用的是e.Row.Item强转成数据模型，然后读模型里的Index属性。这又回到了方案一的老路——模型里的索引不会随排序更新。

修复方式很简单，把读模型属性改成e.Row.GetIndex() + 1。但排查过程提醒我一件事：看到编号错乱，第一反应应该是检查编号来源是数据层还是视图层。数据层的编号在排序过滤后必然出问题，视图层的编号才是可靠的。

5.3 快速滚动时编号闪烁：容器复用导致的视觉残留

在数据量上万、快速拖动滚动条的场景下，偶尔会看到行号“闪一下”才变成正确的值。这是因为容器复用机制：一个刚被回收的行容器，可能还带着上一行的 Header 值，滚动到新位置后，LoadingRow触发并覆盖它，中间有一个极短的过渡。

这个现象不影响正确性，但观感不好。缓解办法是在LoadingRow里先清空再赋值，或者用UnloadingRow事件在容器回收时把 Header 置空：

private void MainGrid_UnloadingRow(object sender, DataGridRowEventArgs e) { e.Row.Header = null; }

加上之后，闪烁基本消失。这个技巧在官方文档里不会写，是实际调出来的经验。

5.4 行头宽度为 0：RowHeaderWidth 未设置

还有一个新手常遇到的问题：行头区域显示了，但宽度是 0，数字被挤没了。原因是RowHeaderWidth默认是double.NaN，也就是自动计算，而行头内容如果是纯数字，可能算出来一个很小的值。

解决办法就是显式给一个宽度，比如RowHeaderWidth="50"。如果你希望宽度自适应内容，可以用RowHeaderWidth="Auto"，但实测在数字位数变化时（比如从 9 变到 10）会有轻微跳动，固定宽度更稳。

6. 进阶：多级编号、分组场景与性能优化

基础需求搞定之后，有些项目会提出更复杂的要求。这一节聊三个进阶话题，都是实际被问到过的。

6.1 分组显示时的组内编号

DataGrid 支持按某列分组（CollectionViewSource.GroupDescriptions）。分组之后，每个组有自己的组头，组内的行如果还想要独立编号，GetIndex()返回的是全局索引，不是组内索引。

要实现组内编号，得换思路：在LoadingRow里判断当前行的分组，然后计算它在组内的位置。可以用CollectionViewSource.GetDefaultView拿到分组信息，遍历组内项找到当前项的位置。代码会复杂一些，但逻辑清晰：

private void MainGrid_LoadingRow(object sender, DataGridRowEventArgs e) { var item = e.Row.Item; var view = CollectionViewSource.GetDefaultView(MainGrid.ItemsSource) as ListCollectionView; if (view != null && view.GroupDescriptions.Count > 0) { foreach (var group in view.Groups) { var collectionGroup = group as CollectionViewGroup; if (collectionGroup != null && collectionGroup.Items.Contains(item)) { int indexInGroup = collectionGroup.Items.IndexOf(item) + 1; e.Row.Header = indexInGroup.ToString(); return; } } } e.Row.Header = (e.Row.GetIndex() + 1).ToString(); }

这个方案在组内数据量不大时没问题，但如果组很多、每组项也很多，每次LoadingRow都遍历分组会有性能开销。优化思路是缓存分组索引，或者改用AlternationIndex配合分组模板，但后者在虚拟化下又不可靠。所以我的建议是：组内编号如果非必须，尽量不做；如果必须做，控制单组数据量。

6.2 大数据量下的性能实测

我用 10 万条数据做过测试，对比开启和关闭虚拟化、以及LoadingRow里做不同操作的耗时。

结论很明确：虚拟化一定要开，LoadingRow里越简单越好。10 万条数据下，只做GetIndex赋值，滚动基本无感；一旦在事件里做集合遍历，帧率就掉下来了。

6.3 行号列 vs 行头：两种视觉方案的取舍

最后聊一个设计层面的选择：序列号到底放在行头（RowHeader）还是放在第一列（Column）？

行头方案的优点是编号和行绑定紧密，视觉上像 Excel 的行号，不占用数据列的空间。缺点是行头样式定制相对麻烦，导出数据时行号不会被包含。

第一列方案的优点是就是一个普通列，样式好控制，导出时也能带上。缺点是要么用 Converter 绑定AlternationIndex（虚拟化有问题），要么用模板列配合LoadingRow手动设置（稍麻烦）。

我的经验是：如果只是界面展示，用行头；如果需要导出、打印、或者用户明确要求“序号列”，用第一列模板列。模板列的实现方式是在LoadingRow里找到那一列的元素并赋值，或者用MultiBinding配合GetIndex的转换器。后者更优雅，但需要写一个IMultiValueConverter，把行对象和 DataGrid 一起传进去算索引。

7. 一套可直接复用的最小实现模板

聊了这么多原理和坑，最后给一份可以直接复制到项目里的最小模板。XAML 和后台代码都齐了，你新建一个 WPF 窗口，把类名改一下就能跑。

XAML 部分：

<Window x:Class="WpfGridDemo.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="DataGrid 序列号示例" Height="450" Width="700"> <Grid> <DataGrid x:Name="MainGrid" AutoGenerateColumns="False" CanUserAddRows="False" HeadersVisibility="Row" RowHeaderWidth="55" EnableRowVirtualization="True" LoadingRow="MainGrid_LoadingRow" UnloadingRow="MainGrid_UnloadingRow"> <DataGrid.RowHeaderStyle> <Style TargetType="DataGridRowHeader"> <Setter Property="HorizontalContentAlignment" Value="Center"/> <Setter Property="VerticalContentAlignment" Value="Center"/> <Setter Property="Background" Value="#F0F0F0"/> <Setter Property="FontWeight" Value="SemiBold"/> </Style> </DataGrid.RowHeaderStyle> <DataGrid.Columns> <DataGridTextColumn Header="订单号" Binding="{Binding OrderNo}" Width="160"/> <DataGridTextColumn Header="客户" Binding="{Binding Customer}" Width="120"/> <DataGridTextColumn Header="金额" Binding="{Binding Amount}" Width="100"/> </DataGrid.Columns> </DataGrid> </Grid> </Window>

后台代码：

using System.Collections.Generic; using System.Windows; using System.Windows.Controls; namespace WpfGridDemo { public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); MainGrid.ItemsSource = new List<OrderItem> { new OrderItem { OrderNo = "A001", Customer = "客户甲", Amount = 1200 }, new OrderItem { OrderNo = "A002", Customer = "客户乙", Amount = 800 }, new OrderItem { OrderNo = "A003", Customer = "客户丙", Amount = 2300 }, new OrderItem { OrderNo = "A004", Customer = "客户丁", Amount = 560 }, new OrderItem { OrderNo = "A005", Customer = "客户戊", Amount = 1780 }, }; } private void MainGrid_LoadingRow(object sender, DataGridRowEventArgs e) { e.Row.Header = (e.Row.GetIndex() + 1).ToString(); } private void MainGrid_UnloadingRow(object sender, DataGridRowEventArgs e) { e.Row.Header = null; } } public class OrderItem { public string OrderNo { get; set; } public string Customer { get; set; } public decimal Amount { get; set; } } }

这份模板覆盖了前面讲的所有要点：HeadersVisibility、RowHeaderWidth、LoadingRow、UnloadingRow、行头样式、虚拟化。你把它跑起来，点列头排序、滚动、删行，编号都会正确刷新。

我个人在实际项目里用这套方案跑了两年多，从几千条到十几万条数据都试过，没出过编号错乱的问题。唯一需要根据业务调整的，就是行头宽度和样式，以及如果要做组内编号，得额外加分组判断逻辑。如果你也在做 WPF 表格相关的开发，希望这些内容能帮你少走几个弯路。