DataTable删除重复行异常：仅删除一行，求代码错误排查

我来帮你梳理下代码里的几个关键问题，这些问题直接导致了你遇到的“本该删除两行却只删了一行”的情况：

1. 循环起始逻辑与异常掩盖 #

你的循环从i=0开始，第一次循环时i-1=-1，访问tbl.Rows[i-1]会直接抛出索引越界异常，但被catch { }空捕获吞掉了——这不仅会掩盖错误，还会让第一次循环的逻辑完全失效。而且后续删除行后，正向循环会跳过部分行：因为删除行后Rows.Count减少，i递增会直接跳过下一个本该检查的行。

2. 数组比较方式完全错误 #

你用founded.ToString() == expected.ToString()来判断两个数组内容是否相同，这是核心错误之一：数组的ToString()方法默认返回的是类型名称（比如System.Object[]），根本不会比较数组里的元素内容。这个判断几乎永远不会为true，即使偶尔触发，也完全是巧合。

3. 删除行时的索引混乱与提交时机错误 #

当你先删除tbl.Rows[i-1]并调用AcceptChanges()，此时DataTable的行数已经减少了1，原来的tbl.Rows[i]现在的索引变成了i-1，再去访问tbl.Rows[i]就会触发索引越界异常，这个异常又被空catch吞掉，所以第二行的删除代码根本没执行——这就是为什么你只看到一行被删除的原因。

4. 处理source列的循环逻辑有问题 #

在循环u处理数组时，你修改了founded和expected数组的长度，但循环条件是u < founded.Length，这会导致循环提前终止或者漏处理元素。比如第一次删除元素后，founded.Length变小，u递增后可能直接超出新的长度，剩下的元素根本没被处理。

修复后的代码方案 #

我提供两种修复思路，你可以根据自己的习惯选择：

方案一：用LINQ分组实现（更简洁可靠） #

通过LINQ按内容分组，直接找到成对的expected和found行，逻辑清晰且避免索引操作的错误：

// 按除source列外的内容分组，筛选出同时包含expected和found的组
var groupedRows = tbl.AsEnumerable()
    .GroupBy(row => 
        // 拼接除source列外的所有元素作为分组键，确保内容相同的行被分到一组
        string.Join("|", row.ItemArray.Where(item => 
            item.ToString() != Constants.VALUE_SOURCE_FOUND && 
            item.ToString() != Constants.VALUE_SOURCE_EXPECTED))
    )
    .Where(g => g.Count() == 2 && 
                g.Any(r => r.ItemArray.Contains(Constants.VALUE_SOURCE_EXPECTED)) && 
                g.Any(r => r.ItemArray.Contains(Constants.VALUE_SOURCE_FOUND)));

// 收集所有需要删除的行
var rowsToDelete = new List<DataRow>();
foreach (var group in groupedRows)
{
    rowsToDelete.AddRange(group);
}

// 批量标记删除
foreach (var row in rowsToDelete)
{
    row.Delete();
}

// 最后统一提交所有修改
tbl.AcceptChanges();

return tbl;

方案二：反向循环实现（贴近原代码逻辑） #

通过反向循环避免删除行后的索引混乱，同时修正数组比较和提交时机的问题：

// 反向循环，从最后一行往前遍历，避免删除行后索引错乱
for (int i = tbl.Rows.Count - 1; i >= 1; i--) 
{ 
    var currentRow = tbl.Rows[i];
    var prevRow = tbl.Rows[i - 1];

    bool isCurrentFound = currentRow.ItemArray.Contains(Constants.VALUE_SOURCE_FOUND);
    bool isPrevExpected = prevRow.ItemArray.Contains(Constants.VALUE_SOURCE_EXPECTED);

    if (isCurrentFound && isPrevExpected) 
    { 
        // 提取除source列外的元素数组
        var founded = currentRow.ItemArray.Where(item => item.ToString() != Constants.VALUE_SOURCE_FOUND).ToArray(); 
        var expected = prevRow.ItemArray.Where(item => item.ToString() != Constants.VALUE_SOURCE_EXPECTED).ToArray(); 

        // 用SequenceEqual正确比较数组元素是否全部相同
        bool areRowsEqual = founded.SequenceEqual(expected);

        if (areRowsEqual) 
        {
            // 先标记删除，不立即提交
            prevRow.Delete();
            currentRow.Delete();
        }
    }
} 

// 所有删除操作完成后，统一提交修改
tbl.AcceptChanges();
return tbl;

关键修复点说明： #

• 反向循环：避免删除行后未遍历的行索引发生变化，确保每一行都能被检查到
• 正确的数组比较：用SequenceEqual()方法判断数组元素是否全部一致，替代错误的ToString()比较
• 延迟提交修改：只在所有删除操作完成后调用一次AcceptChanges()，避免频繁修改DataTable状态导致的问题
• 移除空catch：空捕获会掩盖调试信息，移除后能及时发现潜在的异常问题

内容的提问来源于stack exchange，提问作者Nick S.