C# Winform 用 NPOI 做 Excel 导入导出：选型、实战与避坑指南

1. 先说结论我用 NPOI 而不是 EPPlus 和 COM 组件做 C# Winform 的 Excel 导入导出选型好库项目就成功了一半。我在多个实际项目里试过 COM 组件、EPPlus、NPOI 这三种路子最终固定用 NPOI理由很简单它在自由度和稳定性之间取得了最好的平衡。先说 COM 组件很多老项目还在用 Microsoft.Office.Interop.Excel。这东西在开发机上跑得挺好但部署到客户机器上就是一场灾难必须装 Office、要处理 DCOM 配置、权限问题一大堆。最离谱的一次客户服务器上跑着跑着弹出一个 Office 激活对话框整个导入导出线程直接挂掉最后还是得手动去点掉。所以新项目我劝你别碰 COM除非你确认所有目标机器都预装了 Office 且有桌面会话否则维护成本太高。EPPlus 是另一条路线API 设计得很现代支持图表、透视表这些高级功能。但有个硬伤从 5.0 版本开始它改成了商业授权模式社区版有导出功能限制企业商用需要购买授权。很多团队一开始没注意这个等交付审计的时候被查版权被迫返工换库这是我们当年踩过的真坑。如果你的公司有法务合规要求直接用 NPOI 省心。NPOI 是 Apache 2.0 协议的开源库可以随意商用。它底层封装了 Apache POI 的 Java 实现API 风格稍微老派一点性能不算顶级但做常规报表级别的导入导出完全够用。更关键的是它可以读写 .xls 和 .xlsx 两种格式均无需安装任何 Office 依赖。我在 Win10 到 Win11 的各种环境下跑过没有遇到因为这套库本身引起的兼容性问题。版本方面NuGet 上直接搜 NPOI稳定版推荐 2.5.6 或 2.6.x 系列。注意一点如果你用的是 .NET Framework 4.5 以下的老项目选 NPOI 2.4.1 反而更稳因为新版依赖了一些较新的系统 API。如果你的项目是 .NET Framework 4.7.2 或 .NET 6直接上 2.6.2 就行。2. 基础导出从 DataTable 到 Excel 的完整流程2.1 环境准备和三个核心命名空间在动手写代码前先搞清楚 NPOI 里的三个核心命名空间这决定了你能不能读懂后续所有代码NPOI.SS.UserModel这是统一的接口层不管操作 .xls 还是 .xlsx都对着 IWorkbook、ISheet、IRow、ICell 这些接口写。NPOI.HSSF.UserModelHSSFWorkbook 类在这里对应 Excel 97-2003 的 .xls 格式。NPOI.XSSF.UserModelXSSFWorkbook 类在这里对应 Excel 2007 的 .xlsx 格式。你只需要在业务代码里引用接口层具体的 HSSF 或 XSSF 类在工厂方法里区分。这样的好处是日后如果需要同时支持两种格式不用写两套业务逻辑。安装 NuGet 包Install-Package NPOI -Version 2.6.22.2 最简单的导出方法DataTable 批量输出大部分 Winform 项目的实际需求就是把 DataGridView 绑定的 DataTable 原样导出成 Excel表头用列名数据按行铺开。NPOI 提供了最直接的 API你可以直接把 DataTable 转成 Excelpublic MemoryStream ExportDataTableToExcel(DataTable dt, string sheetName) { IWorkbook workbook new XSSFWorkbook(); ISheet sheet workbook.CreateSheet(sheetName); // 创建表头 IRow headerRow sheet.CreateRow(0); for (int col 0; col dt.Columns.Count; col) { ICell cell headerRow.CreateCell(col); cell.SetCellValue(dt.Columns[col].ColumnName); } // 写数据行 for (int row 0; row dt.Rows.Count; row) { IRow dataRow sheet.CreateRow(row 1); for (int col 0; col dt.Columns.Count; col) { ICell cell dataRow.CreateCell(col); object value dt.Rows[row][col]; if (value null || value DBNull.Value) cell.SetCellValue(string.Empty); else if (value is int || value is long || value is decimal || value is double) cell.SetCellValue(Convert.ToDouble(value)); else if (value is DateTime dtValue) cell.SetCellValue(dtValue); else cell.SetCellValue(value.ToString()); } } MemoryStream ms new MemoryStream(); workbook.Write(ms, true); // 第二个参数 true 表示将工作簿写完后自动关闭 return ms; }这段代码看起来很完整了对吧但实际交付中你会发现几个问题第一列宽全乱。默认列宽是 8 个字符中文表头会显示成“#”用户看到第一眼就觉得这东西不专业。第二日期格式需要特殊处理。上面的代码直接写入 DateTimeExcel 会显示成一串数字需要在 Excel 里手动设置单元格格式才能显示正确格式。第三表头样式没有加粗或底色视觉上分不清表头和正文。所以实际项目里我会加一段样式设置代码这部分是最能体现“细节与专业度”差异的地方。2.3 带上样式和列宽让导出结果更专业专业导出至少要处理三样东西表头背景色加粗、日期格式、列宽自适应。代码如下private void ApplyHeaderStyle(ISheet sheet, ICellStyle headerStyle, int columnCount) { IRow headerRow sheet.GetRow(0); for (int col 0; col columnCount; col) { ICell cell headerRow.GetCell(col); cell.CellStyle headerStyle; } // 冻结表头行方便查看大数据量 sheet.CreateFreezePane(0, 1); } private ICellStyle CreateHeaderStyle(IWorkbook workbook) { ICellStyle style workbook.CreateCellStyle(); style.FillForegroundColor NPOI.HSSF.Util.HSSFColor.Grey25Percent.Index; style.FillPattern FillPattern.SolidForeground; // 设置边框 style.BorderTop BorderStyle.Thin; style.BorderBottom BorderStyle.Thin; style.BorderLeft BorderStyle.Thin; style.BorderRight BorderStyle.Thin; // 字体加粗 IFont font workbook.CreateFont(); font.IsBold true; style.SetFont(font); return style; }日期格式的单元格需要额外创建带格式化字符串的单元格样式private ICellStyle dateCellStyle; dateCellStyle workbook.CreateCellStyle(); dateCellStyle.DataFormat workbook.CreateDataFormat().GetFormat(yyyy-MM-dd HH:mm:ss);然后在写单元格数据时判断一下类型如果是 DateTime 就设这个样式。在项目里我还遇到过需要把“2024-01-15”这样的字符串识别成日期格式的情况可以用 DateTime.TryParse 先尝试转换成功就按日期写入失败则按普通字符串处理。这个细节能帮你省去用户手动调格式的时间。列宽自适应是个经典话题NPOI 虽然内置了 sheet.AutoSizeColumn 方法但对中文支持很差。它根据字符数估算宽度但中文字符在此方法计算中会被低估结果列宽明显偏窄。我的做法是统一绕过这个方法自己估算宽度中文字符按 2 个英文字符宽度算private void AutoSetColumnWidth(ISheet sheet, int columnCount, int maxColumnCharCount 30) { for (int col 0; col columnCount; col) { int maxWidth 10; // 最小值兜底 for (int row 0; row sheet.LastRowNum; row) { IRow currentRow sheet.GetRow(row); if (currentRow null) continue; ICell cell currentRow.GetCell(col); if (cell null) continue; string cellValue cell.ToString(); int charCount GetWidthOfString(cellValue); if (charCount maxWidth) maxWidth charCount; } sheet.SetColumnWidth(col, maxWidth * 256); } } private int GetWidthOfString(string text) { int len 0; foreach (char c in text) { // 基本按中文字符宽度加倍处理 len (c 127) ? 2 : 1; } return len; }注意这里的 SetColumnWidth 单位是 1/256 个字符宽度所以要将字符数乘以 256。这个细节不搞清楚你设列宽时数字会大得离谱。实际调试中我发现乘完 256 后宽度值不够直观但这是 NPOI 的既定单位习惯就好。2.4 多 Sheet 导出与命名限制真实业务里很多时候一个 Excel 文件要包含多个 Sheet比如一张汇总表、一张月明细表、一张操作日志表。NPOI 支持在一个 IWorkbook 里创建多个 ISheet然后一次性写入同一个 MemoryStreamISheet summarySheet workbook.CreateSheet(汇总); ISheet detailSheet workbook.CreateSheet(明细);但也有个坑Sheet 名称有长度限制最多 31 个字符并且不能包含: \ / ? * [ ]这些字符。如果用户输入了一个很长的表名直接调用 CreateSheet 会抛 ArgumentException。我一般会写个辅助方法超过 30 个字符就截断。否则用户随便填一个超长的名称程序就莫名其妙崩了排查起来很头疼。3. 导入功能Excel 到 DataTable 的稳健解析3.1 从文件对话框到数据解析的完整链路导入功能的基本链路是OpenFileDialog 选文件 → 获取文件流 → 用 NPOI 打开工作簿 → 遍历 Sheet 行列 → 写入 DataTable → 绑定 DataGridView。选文件时我会设置 Filter 同时支持 .xls 和 .xlsxOpenFileDialog dialog new OpenFileDialog { Filter Excel 文件|*.xls;*.xlsx, Multiselect false }; if (dialog.ShowDialog() DialogResult.OK) { DataTable dt ReadExcelToDataTable(dialog.FileName); dataGridView1.DataSource dt; }这里有个隐蔽问题如果你只写了*.xlsx老客户从某个历史系统导出的 .xls 文件就打不开了。反过来只写*.xls现代 Office 默认保存的 .xlsx 又不行。所以必须两个都放。读取的核心函数public DataTable ReadExcelToDataTable(string filePath) { DataTable result new DataTable(); using (FileStream fs new FileStream(filePath, FileMode.Open, FileAccess.Read)) { IWorkbook workbook WorkbookFactory.Create(fs); ISheet sheet workbook.GetSheetAt(0); // 默认读取第一个 Sheet // 表头 IRow headerRow sheet.GetRow(0); for (int col 0; col headerRow.LastCellNum; col) { ICell cell headerRow.GetCell(col); string colName cell?.ToString()?.Trim(); if (string.IsNullOrEmpty(colName)) colName 列 (col 1); result.Columns.Add(colName); } // 数据行 for (int row 1; row sheet.LastRowNum; row) { IRow dataRow sheet.GetRow(row); if (dataRow null) continue; DataRow dr result.NewRow(); for (int col 0; col result.Columns.Count; col) { ICell cell dataRow.GetCell(col); dr[col] GetCellValue(cell); } result.Rows.Add(dr); } } return result; }这段代码能跑通 80% 的基础场景但有几个点会让你在真实数据面前怀疑人生合并单元格、日期格式读取偏差、全空行误入。接下来逐个拆解。3.2 处理空行、合并单元格和类型转换先说空行问题。很多用户会在 Excel 里按好多下行表格样式有边框但实际没有任何内容。这种行如果直接 Add 到 DataTable会出现一整行 NULL 数据后续导入到数据库时容易引发约束冲突。我的处理是扫描该行所有单元格如果全部为空或只有空白字符就跳过。再说合并单元格。NPOI 读取合并单元格时只有左上角的单元格有值其余合并区域里的单元格返回 null。如果你的程序需要完整填充这部分数据可以借助 NPOI 的 MergedRegion 信息做一次“展开”处理。实现思路是private void FillMergedCells(ISheet sheet) { // 收集所有合并区域 for (int i 0; i sheet.NumMergedRegions; i) { CellRangeAddress range sheet.GetMergedRegion(i); ICell topLeftCell sheet.GetRow(range.FirstRow)?.GetCell(range.FirstColumn); if (topLeftCell null) continue; object mergedValue GetCellValue(topLeftCell); for (int r range.FirstRow; r range.LastRow; r) { for (int c range.FirstColumn; c range.LastColumn; c) { IRow row sheet.GetRow(r); if (row null) row sheet.CreateRow(r); ICell cell row.GetCell(c); if (cell null) cell row.CreateCell(c); cell.SetCellValue(mergedValue.ToString()); } } } }这个逻辑不复杂但要注意对大型合并区域的性能影响不要每次都全表扫描合并区域最好在读取数据前只做一次。我在五万行、几十个合并区域的测试数据上跑过耗时在几百毫秒左右可以接受。最后是类型转换。Excel 里单元格看起来是日期但内部存储可能是数字序列号。NPOI 提供了一个便捷的判断DateUtil.IsCellDateFormatted(cell)加上它就能正确处理日期private object GetCellValue(ICell cell) { if (cell null) return null; switch (cell.CellType) { case CellType.Boolean: return cell.BooleanCellValue; case CellType.Numeric: // 判断是否日期格式的单元格 if (DateUtil.IsCellDateFormatted(cell)) return cell.DateCellValue; double numericValue cell.NumericCellValue; // 如果数值没有小数部分尽量转成整数避免出现 1.0 这样的显示 if (Math.Abs(numericValue - Math.Floor(numericValue)) 0.0000001) return (long)numericValue; return numericValue; case CellType.Formula: // 公式单元格用缓存值返回 return GetCellValueByCachedResult(cell); default: return cell.ToString()?.Trim(); } }有一个容易被忽略的坑数字列中有个别的单元格被用户设置成文本格式此时这个单元格的值是“12345”字符串但同一列其他格子是真正的数字。在统一处理时建议全部先转成字符串再进 DataTable或者对 DataTable 每一列做一次统一的类型推断。我在项目里采用的做法是先全部按字符串读入 DataTable再让用户选择目标映射关系在写入数据库时做类型转换。这样虽然多了一步但避免了 Excel 格式混乱带来的类型推断错误。3.3 从 DataGridView 反选数据再导出的常见做法还有一个高频需求是用户在 DataGridView 里通过鼠标选择了部分行然后点“导出选中行”。这种场景不能用导出 DataTable 的逻辑要直接从 DataGridView 里取选中行构造一个 DataTableDataTable selectedTable new DataTable(); foreach (DataGridViewColumn col in dgv.Columns) { selectedTable.Columns.Add(col.HeaderText); } foreach (DataGridViewRow row in dgv.SelectedRows) { DataRow dr selectedTable.NewRow(); foreach (DataGridViewColumn col in dgv.Columns) { dr[col.HeaderText] row.Cells[col.Index].Value?.ToString() ?? ; } selectedTable.Rows.Add(dr); }注意一个陷阱如果 DataGridView 的 SelectionMode 设置成了 FullRowSelect这个逻辑没有问题但如果用户只选了单元格而非整行SelectedRows 为空代码会没有反应。更好的做法是同时处理 SelectedCells反向推导出所有相关的行对象再过滤去重。我在代码里加了一个函数遍历所有选中 Cells取每个 Cell 的 RowIndex放入 HashSet 去重然后再逐行导出。4. 我踩过的那些坑附带排查链路这一节全是实际项目中遇到过的问题比书上写的“最佳实践”更有参考价值。每个问题我尽量还原当时的现象和排查路径。4.1 EPPlus 5.0 开始的授权问题当年我在某公司做报表导出功能开发时图 EPPlus API 简洁直接用了当时最新的 5.1 版。本地测试一切正常交付预发布环境时项目经理拿了对账单模板来验证结果报表一导出来前几行还正常后续数据全被替换成注释文字。仔细一查才发现是 EPPlus 5.0 的限制社区版只支持非商业用途。排查过程是这样的先看日志没有任何异常抛出。将导出的文件和本地文件对比发现多了几行警告文本。搜索警告文本才定位到 EPPlus 官方说明页面。解决方式有两种一是买 Polyform Noncommercial 之外的商业授权二是换掉 EPPlus。基于成本考虑最终把整个报表模块重写为 NPOI。后来我在其他项目里也养成了一个习惯选第三方库时先看授权协议再考虑 API 友好程度。这个顺序不能反。4.2 十万行数据导出时的内存暴涨与 OOM第一次导出十万行、四十列的数据时我用的是 XSSFWorkbook 直接写到 MemoryStream。程序跑起来内存占用一度冲到 2GB32 位进程强制报 OOM。后来定位到原因XSSFWorkbook 把所有单元格数据全部加载进内存并建立了完整的 XML 节点树十万行是个分水岭。解决办法是用 SXSSFWorkbook也就是 POI 提供的流式写入实现。SXSSFWorkbook 会控制内存中保留的行数超出部分自动刷到磁盘临时文件。NPOI 里也有对应的类写法是这样SXSSFWorkbook workbook new SXSSFWorkbook(100); // 内存中保留 100 行 ISheet sheet workbook.CreateSheet(Sheet1);注意SXSSFWorkbook 是专门写 .xlsx 的项目里如果还要兼容 .xls需要另外处理。但实际业务中十万行数据一般不会要求导出 .xls毕竟 .xls 本身的格式上限就是 65536 行。所以这个限制问题不大。顺带一提导出大数据量时即便用 SXSSF 减少了内存占用程序本身的 DataTable 可能也已经占了大量内存。我通常建议导出前先对数据做裁剪或分页不要让 DataGridView 一次加载全部数据。如果你的业务真的需要一次导出五十万行那建议直接在 SQL 层面做分页读取边取边写文件而不是先把 DataTable 全装进内存再导。这属于“导出架构”层面的话题等有空我再单独写一篇展开。4.3 .xls 和 .xlsx 混用时 WorkbookFactory 为什么重要早期我用 NPOI 写代码时为了图快总是直接 new HSSFWorkbook(fs) 或 new XSSFWorkbook(fs) 来处理固定格式。但客户发来的文件常常是混合的有时是旧系统导出的 .xls有时是 Excel 2019 保存的 .xlsx。用错了构造函数就直接抛异常。后面改成统一用 WorkbookFactory.Create(fs)这个方法会自动根据文件头判断实际格式然后返回对应的 IWorkbook 实例。它的底层逻辑很简单读取文件的前 8 个字节判断魔数如果是 D0 CF 11 E0 A1 B1 1A E1 就是 OLE2 复合文档.xls如果是 50 4B 03 04 则是 ZIP 包.xlsx 本质是一个 ZIP 压缩包。这种方式比用文件扩展名判断可靠得多。因为有些客户会把 .xlsx 文件改名成 .xls 再发过来你要是只按扩展名选解析器照样翻车。我在辅助函数里专门加了日志记录 WorkbookFactory 实际检测到的格式方便排查这类问题。4.4 导出后被 Excel 提示“文件已损坏是否尝试修复”这个问题很隐蔽。我的一个错误版本代码在写入 MemoryStream 之后又用同一个流去读取导致 Stream 位置不对Excel 打不开导出的文件。排查过程用 Notepad 打开导出的 .xlsx 文件发现开头是乱码说明文件确实有内容。用压缩工具强制解压 .xlsx发现内部 XML 结构缺失。回溯代码定位到 Stream 操作后没有重置 Position 或重复 Write。标准做法是每次导出都用MemoryStream ms new MemoryStream();写完workbook.Write(ms, true);后如果需要立刻读取这个流再ms.Position 0。导出的文件必然要先由用户保存到本地所以你只要确保最终写入的流是完整的就没什么问题。另一个常见场景是用FileStream而不是MemoryStream直接写文件。其实 NPOI 支持直接向 FileStream 写入这在数据量大的时候反而更省内存using (FileStream fs new FileStream(savePath, FileMode.Create, FileAccess.Write)) { workbook.Write(fs, true); }但注意如果中途抛出异常文件可能不完整最好用 try-catch 把异常信息记录下来并告知用户重新操作。4.5 特殊字符与公式注入问题Excel 的单元格里如果写入以、、-、开头的文本Excel 会把它当公式处理甚至可能触发外部链接访问。这在导入导出安全审查中是个常见红线。我们这边有次导出一批从用户系统收集的备注信息某个备注内容恰好以25开头结果用户打开 Excel 后看到的不是文本而是计算结果 7差点造成数据理解错误。解决方案是在导出用户可控文本时做一层“清洗”如果字符串以危险字符开头就在前面加一个单引号Excel 会把它当作纯文本显示。同时建议在读取导入数据时也做一次校验发现公式类型单元格CellType.Formula时用缓存结果而不是重新计算公式避免脚本注入。这也是很多安全规范里的基础要求。5. 工程化思路封装一个通用的 ExcelHelper5.1 明确 API 边界导出到哪一层才算“够用”写到这里你应该已经掌握了导入导出的核心技术点。但真实项目里你通常不会在每个窗口里都写一遍这些逻辑。工程化的做法是封装一个ExcelHelper类把核心操作抽象成几个方法public static class ExcelHelper { /// summary /// 导出 DataTable 到 Excel单 Sheet /// /summary public static MemoryStream Export(DataTable dt, string sheetName, bool autoWidth true); /// summary /// 导出多个 DataTable 到 Excel多 Sheet /// /summary public static MemoryStream ExportMultiple(Dictionarystring, DataTable sheets); /// summary /// 读取 Excel 文件内容返回 DataTable默认第一个 Sheet /// /summary public static DataTable Import(string filePath, int sheetIndex 0); /// summary /// 读取 Excel 文件的所有 Sheet 名称 /// /summary public static Liststring GetSheetNames(string filePath); }方法签名不要设计得太细。比如让调用方传入样式参数、合并单元格策略等需求变化后会变得很难维护。我的经验是默认做一个“看起来不错”的样式提供一两个可选的 bool/参数开关其他特殊情况在具体页面里再做扩展而不是把 Helper 做成一个大水桶。GetSheetNames 这个方法要单独拎出来是因为导入时经常需要让用户在下拉框里选“要导入哪一个 Sheet”。很多新手直接在导入代码里强制取第 0 个 Sheet一旦 Excel 文件的第一个 Sheet 是封面或说明数据解析就全乱了。5.2 异步化与 UI 冻结问题Winform 的 UI 线程非常脆弱一旦导入导出耗时长窗口就会陷入“未响应”的假死状态。我第一次把十万行导出功能挂到界面上时整个窗口大约卡了十几秒客户还以为程序崩溃了。解决思路很简单用async/awaitTask.Run把数据解析和文件读写的耗时操作放到线程池。UI 线程只负责启动任务、展示进度条和控制按钮禁用状态。比如private async void btnExport_Click(object sender, EventArgs e) { btnExport.Enabled false; progressBar1.Visible true; progressBar1.Value 0; try { DataTable dt (DataTable)dataGridView1.DataSource; await Task.Run(() ExportToFile(dt, savePath)); MessageBox.Show(导出成功, 提示, MessageBoxButtons.OK, MessageBoxIcon.Information); } catch (Exception ex) { MessageBox.Show($导出失败{ex.Message}, 错误, MessageBoxButtons.OK, MessageBoxIcon.Error); // 记录日志 } finally { btnExport.Enabled true; progressBar1.Visible false; } }如果你想显示百分比进度而不是转圈那就要把“遍历 DataTable 写入 Excel”这个过程拆成多批次每完成一批就通过IProgressint回调 UI 更新进度条。注意NPOI 本身不给进度反馈所有进度计算都是你自己控制的。比较通用的做法是先统计总行数每写完 100 行报告一次进度转换成百分比。我在项目中用这种方案用户体验明显提升。另外还有一点在 Task.Run 里操作 DataTable 要小心如果它仍然绑定在 DataGridView 上后台线程读取数据没问题但如果有其他逻辑在同一个 DataTable 上做增删改会有线程冲突。稳妥起见导出前先dt.Copy()一个副本再传给后台线程。5.3 日志与错误处理导入导出是业务系统中出错率较高的模块错误处理不能只是弹个 MessageBox。我建议至少记录以下几类信息哪个文件导入/导出了文件大小多少。导出的 Sheet 名称和行数。读取时跳过多少空行、多少个公式单元格。异常堆栈以及出错时的单元格位置Sheet Row Column。这些日志在夜班维护时非常有用。比如用户报了一个“导入报错”如果你连文件名都没记录排查只能靠盲猜。我给 ExcelHelper 内部加了一个静态的 Action 日志回调调用方可以注入自己的日志对象灵活性和侵入性都不高。6. 再聊几个生产环境下才用得上优化细节这部分内容是我在多个项目中反复打磨出来的属于“别人文档里不会写但实际很常见”的操作。第一Excel 模板复用。如果你的业务需要一个固定的报表格式比如公司 Logo 放在顶部、指定合并单元格、固定列宽那么不要每次用代码去重新生成全套样式。更稳妥的做法是先在 Excel 里做好模板文件比如模板.xlsx然后让 NPOI 读取模板文件填充数据后另存为新文件。NPOI 对模板文件的样式、合并单元格都能完整保留你只需要维护一个模板文件而不是维护一大段样式代码。这也是业界主流做法。第二列顺序映射。导入时用户上传的 Excel 列顺序可能和你的数据库表不一致比如数据库是“姓名、工号、部门”Excel 里却是“工号、部门、姓名”。我用一个 DataGridView 让用户可视化配置“Excel 列 → 系统字段”的对应关系选好后保存映射配置下次同一模板的用户可以自动匹配。这个功能听上去只是一个小优化却大幅降低了用户手动调整 Excel 的工作量。第三自动编号列。有些业务要求在导出结果里增加“序号”列行号 1、2、3……我建议在导出时直接写入但要注意序号列首列是表头“序号”数据行按行号递增。如果你把row index 1直接当作序号遇到中间有空行跳过时会不连续。所以序号应该是通过自增计数变量而不是行号计算得到。这是一个很小的细节但我在代码评审时已经见过太多次类似的低级失误。第四临时文件和内存流的取舍。数据量不大一万行以内MemoryStream 便于继续加工和回传用起来方便。数据量大超过五万行直接写 FileStream 落盘避免大对象进入大对象堆LOH导致 GC 压力。另外注意在 64 位系统上如果不小心把项目配置成了 x86内存上限只有 2GB导出大文件时必炸。如果是给客户部署优先使用 AnyCPU 或明确指定 x64。第五兼容性验证。你需要准备一套“标准测试文件”包括 .xls 和 .xlsx 两种格式分别含日期、公式、合并单元格、数字文本混排、空行、超长文本等特征每次升级 NPOI 版本后都跑一遍回归测试。我在某个项目里升级 NPOI 版本后发现旧版创建的某些单元格样式出现轻微偏移如果不是提前跑了回归测试上线后用户第一个导入操作就会发现问题。所有版本的升级测试都不可以跳过。收个尾吧。如果你刚开始在一个 Winform 项目里做 Excel 导入导出我建议的路子是先用 NPOI 把最基本的导出 DataTable、读取 Excel 的代码跑通再逐一把样式、日期格式、合并单元格、异步化和错误处理这些细节点补上。这中间一定会踩到一些坑但只要把每个问题的“前置条件”和“排查链路”记录下来后续做任何其他数据交换功能都会顺畅很多。毕竟 Excel 处理不是一锤子买卖下次遇到的模板大概率又会出现你没见过的格式问题而之前积累的这套处理框架和排查经验才是你最重要的工作资产。