Blazor WASM中使用iText生成4k行大表格触发GC内存分配错误

Blazor WASM运行在浏览器沙箱环境中，可用的GC堆内存远低于桌面/服务器端.NET运行时，且WASM的GC性能较弱。iText 7的LargeTable模式Flush操作虽然设计初衷是降低内存占用，但iText原生并没有针对WASM环境做适配，每次Flush都会生成大量临时对象，频繁调用很容易触达WASM的内存上限，抛出你遇到的分配失败错误，该问题已有大量Blazor WASM做PDF导出的开发者反馈过。

• 调整Flush触发阈值：不要每50行触发一次Flush，建议调整为每200~300行触发一次，减少临时对象生成频率，避免频繁GC压力。
• 拆分大Table为多个小实例：不要全局持有同一个大Table对象，每生成200行就把当前Table完成后加入文档，再新建新的Table实例继续生成剩余行，旧Table实例会被GC及时回收，能降低70%以上的峰值内存占用。如果需要重复表头，每个小Table都添加相同的表头即可。
• 关闭非必要的LargeTable模式：如果你的业务不需要PDF跨页时自动重复表头，可以把new Table(5, true)的第二个参数设为false，关闭LargeTable模式，内存占用会进一步降低。
• 后端生成方案（最稳妥）：如果表格行数还会继续增长，建议把PDF生成逻辑迁移到后端API，前端仅传递筛选参数，后端生成完成后返回文件流供前端下载，完全避开Blazor WASM的内存限制。

// 按200行拆分的示例
const int batchSize = 200;
var totalCount = FilteredItems.Count;

for (int batch = 0; batch < Math.Ceiling((double)totalCount / batchSize); batch++)
{
    var currentBatch = FilteredItems.Skip(batch * batchSize).Take(batchSize).ToList();
    var dataTable = new Table(5, true)
        .UseAllAvailableWidth()
        .SetBorder(Border.NO_BORDER);
    // 每个批次都加表头
    dataTable.AddColumnHeader("Header 1");
    dataTable.AddColumnHeader("Header 2");
    dataTable.AddColumnHeader("Header 3");
    dataTable.AddColumnHeader("Header 4");
    dataTable.AddColumnHeader("Header 5");
    document.Add(dataTable);
    
    foreach (var item in currentBatch)
    {
        dataTable.AddColumnData(item.Item1);
        dataTable.AddColumnData(item.Item2);
        dataTable.AddColumnData(item.Item3);
        dataTable.AddColumnData(item.Item4);
        dataTable.AddColumnData(item.Item5);
    }
    
    dataTable.Complete();
    // 批次处理完成后主动触发GC回收（可选，WASM下可加速内存释放）
    GC.Collect();
}

document.Close();

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