如何优化批量Excel文件读取合并至DataTable的运行效率

你当前代码存在多处明确的性能瓶颈，是处理速度随文件量上涨陡降的核心原因：

• 采用Microsoft.Office.Interop.Excel做读取是最大开销来源：该组件是COM互操作方案，每次调用都要跨进程通信，单文件启动Excel进程的额外开销极高，且现有代码存在COM对象泄漏问题，处理文件越多后台残留的Excel进程越多，会持续占用系统资源拖慢速度。
• 存在冗余无效逻辑：读取每个文件前先新建一个空工作簿，后续又直接用打开的目标文件覆盖该对象，平白增加无意义的资源消耗。
• 循环逻辑设计低效：外层遍历列、内层遍历行的顺序不符合DataTable的行式存储特性，且在循环内部用try-catch做类型分支判断，异常捕获的开销是普通类型判断的上百倍，大量单元格触发异常时会严重拖慢速度。
• 串行处理+低效合并：单线程逐个处理文件，且每次读取单个文件后都调用DataTable.Merge做全表结构匹配和数据复制，数据量增大后开销呈线性上涨。
• 空异常捕获吞掉所有错误，出现文件损坏、格式不兼容问题时无法快速定位，也会导致异常场景下资源无法正常释放。

1. 优先替换Interop为轻量纯托管Excel库 #

彻底弃用Microsoft.Office.Interop.Excel，该方案本身就不适合批量数据处理场景，依赖本地安装Office、进程开销大、稳定性差。直接选用以下任意一个纯托管库即可获得数倍到数十倍的读取速度提升：

• MiniExcel：内存占用极低，大文件处理速度最快，API简单，支持直接读取到DataTable/实体类
• NPOI：生态成熟，对老版本xls格式兼容性好
• 直接用你已经引入的ClosedXML做读取，不需要额外引入Interop，避免跨进程通信开销

2. 修正现有代码的低效逻辑 #

如果暂时无法替换组件，先修复代码里的冗余和低效问题：

• 删除无意义的空工作簿创建逻辑：Workbook wb = excel.Application.Workbooks.Add(); 这行完全多余，后续Open方法会返回新的Workbook对象。
• 调换循环顺序，改为外层遍历行、内层遍历列，匹配DataTable行存储的特性，避免频繁按索引跨列取行。
• 删除循环内的try-catch类型判断，所有单元格值直接判空后ToString即可，不需要额外转double，从根源避免异常开销：

// 替换原循环内的try-catch块
object rawVal = data[rCnt, cCnt];
cellVal = rawVal == null ? string.Empty : rawVal.ToString();

• 正确释放COM对象，避免后台残留Excel进程：每次处理完文件后按顺序释放Range、Worksheet、Workbook、Application对象，调用Marshal.FinalReleaseComObject彻底释放资源，不要只调用Quit。
• 弃用DataTable.Merge：提前统一主表的表结构，读取单个文件的DataTable后直接逐行Import到主表，避免每次合并都做全表Schema校验。
• 移除空catch块，至少添加错误日志记录，避免异常时资源无法释放、问题无法定位。

3. 并行处理文件读取 #

文件读取属于IO+CPU混合密集型操作，在CPU核心足够的情况下，用Parallel.ForEach或者Task并行处理多个文件的读取逻辑，注意：

• 若暂时保留Interop方案，需要为每个线程单独创建Application实例，不要跨线程共用COM对象，遵守STA线程模型要求
• 若替换为纯托管库，并行处理没有线程模型限制，安全度更高，速度提升更明显
• 注意控制并行度，不要同时开启过多线程导致磁盘IO打满，一般并行度设置为CPU核心数即可获得最优效果。

4. 写入环节优化 #

如果合并后的数据量较大，不要一次性把整个DataTable加载到ClosedXML的Worksheet中，可以采用分批写入的方式降低内存占用；换用MiniExcel做增量写入的话，大文件写入速度还能再提升3~5倍。

替换为纯托管库+并行处理+逻辑修正后，100个常规大小Excel文件的合并耗时通常可以从10分钟压缩到10~20秒区间，内存占用也会降低80%以上，同时不会有后台残留Excel进程的问题。

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