求助：BlockingCollection<T> GetConsumingEnumerable分块后最后块丢失

问题根源 #

你的Split方法在处理BlockingCollection<T>.GetConsumingEnumerable时丢失最后一个批次，主要有两个原因：

1. 未标记集合完成：测试代码中向BlockingCollection添加完元素后，没有调用CompleteAdding()，导致GetConsumingEnumerable的枚举器一直等待新元素，不会正常终止。
2. 原实现的阻塞风险：原Split方法在生成批次时，会在获取当前元素后额外尝试调用size-1次MoveNext()。对于BlockingCollection，当没有更多元素且未标记完成时，这些MoveNext()会阻塞，直到超时或集合完成，最终导致最后一个元素的批次无法正常返回。

修正后的测试代码 #

首先需要在添加完元素后调用CompleteAdding()，告诉枚举器没有更多元素：

Task.Run(() =>
{
    foreach (var x in Enumerable.Range(0, 10))
    {
        queue.Add(x);
    }
    queue.CompleteAdding(); // 必须调用，终止枚举器等待
});

重构后的Split扩展方法 #

改用更简洁且适配流式场景的实现，避免额外的阻塞式MoveNext()调用：

public static IEnumerable<List<T>> Split<T>(this IEnumerable<T> data, int size)
{
    if (size <= 0)
        throw new ArgumentOutOfRangeException(nameof(size), "批次大小必须大于0");

    var batch = new List<T>(size);
    foreach (var item in data)
    {
        batch.Add(item);
        if (batch.Count == size)
        {
            yield return batch;
            batch = new List<T>(size); // 重置批次容器
        }
    }

    // 返回剩余元素，即使不足批次大小
    if (batch.Count > 0)
    {
        yield return batch;
    }
}

为什么这个方案有效 #

• 遍历过程中直接收集元素，每达到批次大小就返回，避免了原实现中嵌套枚举带来的阻塞风险。
• 枚举结束后（无论是普通集合还是已标记完成的BlockingCollection），会自动返回剩余的元素，确保不会丢失最后一个不完整批次。
• 代码逻辑更清晰，同时保留了流式处理的特性，适合数据库批量插入等IO场景。

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