DataRow.SetField在删除并重新添加DataTable列后抛出空引用异常的原因探究

你遇到的这个问题其实是DataTable内部状态管理和DefaultView交互时的一个典型陷阱，咱们一步步拆解背后的原因：

核心触发点：DataTable列生命周期与内部状态的不一致 #

当你第一次完成排序后删除临时列（比如原列名Sort）并调用AcceptChanges()时，表面上DataTable的列集合已经移除了该列，但有两个容易被忽略的细节导致了二次操作的异常：

1. DataRow的列缓存残留：DataRow对象内部会缓存列的索引和引用，当你删除列后，虽然DataTable的Columns集合已经更新，但已存在的DataRow可能还保留着对旧列位置的无效引用。第二次添加同名列时，新列的索引大概率和旧列不同，SetField通过列名查找时，内部可能错误映射到了旧列的无效索引，最终抛出空引用异常。
2. DefaultView的排序状态残留：你通过DefaultView排序并复制数据到sortedData时，DefaultView的Sort属性是直接绑定在原data对象上的。第一次排序完成后，DefaultView的排序表达式仍然保留着对临时列的引用——即使你删除了该列，DefaultView的内部状态并没有被完全重置。这种“视图状态与实际列结构不匹配”的矛盾，会导致原data的内部数据管理逻辑出现混乱，二次添加同名列时就触发了异常。

为什么你的解决方法能生效？ #

当你选择保留data中的临时列、只删除sortedData中的临时列时，本质上是维持了原data的列结构稳定性：

• 避免了DataRow内部列缓存失效的问题，列的索引和引用始终一致
• 消除了DefaultView因列结构频繁变更导致的状态不一致
• 配合sortedData.Clear()操作，确保每次复制的都是最新排序后的干净数据，不会残留旧状态

额外验证建议（可选） #

如果你想进一步验证这个推测，可以做两个小测试：

• 第二次添加临时列后，打印data.Columns[sortColumnNames[k]].Ordinal（列的索引值），对比第一次添加时的索引。如果两者不一致，说明新列的位置和旧列不同，DataRow的缓存映射确实出了问题
• 第一次删除临时列后，主动调用data.DefaultView.Sort = string.Empty清空排序状态，再尝试二次排序操作，看是否还会触发空引用异常

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