做.NET开发这些年凡是跟管理系统沾边的项目几乎都躲不开一个需求导出Excel。客户嘴上说的是“就一个简单导出”等真正提需求的时候往往还要跟着“要有合计行、要加颜色、日期格式要YYYY-MM-DD、数据好几万行别卡死”。网上关于C#导出Excel的帖子很多但多数只讲其中一种讲NPOI的举NPOI的例子讲EPPlus的说EPPlus香。我比较少看到有人把这几种办法放在一起、客观地把适用场景说清楚。所以这篇干脆把我在实际项目里用过的6种方案——CSV、HTML表格、NPOI、EPPlus、MiniExcel现更名MnExcel和COM互操作——完整过一遍代码都给到能直接跑的程度坑也一块儿说了。如果你是刚入行的.NET程序员这篇可以帮你少走弯路如果你已经在项目里被导出功能坑过那这篇的对比和踩坑部分应该能让你会心一笑。1. 为什么同一个“导出Excel”会有六条路1.1 先明确需求你被“导出”两个字骗了多少次“导出Excel”在技术实现上根本没有统一答案因为“Excel文件”这个词本身就很模糊。它可能指二进制格式的.xls、Office Open XML格式的.xlsx、逗号分隔的CSV纯文本甚至一个Excel能识别的HTML文件。需求端也千差万别有的只是把表格里的几十条数据导出去归档有的要生成带图表、带合并表头的复杂财务报告有的是定时任务每天导出几十万行明细再交给其他系统处理。这几种场景对工具的要求完全不同。一开始接触这个需求的人第一反应往往是上网搜“C# 如何导出Excel”然后跟着教程装一个COM组件代码跑通那一瞬间觉得自己成功了。等部署到服务器上问题就来了服务器没装Excel、运行时权限不够、Excel进程反复残留最后不得不推倒重来。说实话这几乎是每个做导出功能的.NET开发者都走过的弯路。所以我建议在做技术选型前先想清楚四件事目标环境有没有装Excel、数据量大概多大、格式复杂度到了什么级别、输出通道是Web下载还是本地文件。这四个问题答案直接决定后面选哪条路。1.2 六种方案的横向对比表先把六种方案放在一张表里看心里就有底了。方案是否生成真实Excel依赖成本格式能力性能表现典型场景CSV否Excel可打开零依赖弱极高简单明细导出、系统间数据交换HTML表格否Excel可打开零依赖中中Web报表快速下载NPOI是无NuGet包中强xls/xlsx中.NET Framework老项目、读写兼顾EPPlus是无注意License强图表/透视表/图片中复杂格式专业报表MiniExcel / MnExcel是无NuGet包中高大数据量导出、轻量项目COM互操作是必须安装Excel强低本地自动化脚本表里的“性能表现”指的是大数据量下的表现。CSV为什么性能极高因为本质就是拼字符串CPU、内存都省MiniExcel性能高是因为设计上就冲着低内存流式写入去的COM性能低是因为每步操作都在和一个外部进程通信慢得让人着急。1.3 怎么选才不至于翻车这里给一个可参考的决策路径实际项目我基本就是这样快速判断的只是导出表格数据没有复杂格式要求选CSV。成本为零前端还能直接打开。要在浏览器里点一下下载对样式有一点要求但不想引库HTML方案应急很合适。项目还在.NET Framework 4.x时代或者需要读取Excel模板再写入数据NPOI最稳。要做带图表、带图片、带数据透视表的专业报表EPPlus功能最强。数据量动不动就是几十万行或者对内存占用敏感MiniExcel是首选。COM互操作能不碰就别碰尤其不要部署到服务器上。这段路径不绝对但能解决大部分选型纠结。下面逐个展开每个方案我都给完整代码和注意事项。2. 第一种CSV——零依赖的极简导出2.1 CSV为什么能当Excel用CSV的全称是Comma-Separated Values本质上是逗号分隔的纯文本。它的扩展名.csv在Windows上默认关联Excel双击就能打开Excel会按逗号拆列。它并不是Excel原生格式但绝大多数时候用户不关心文件内部是什么打开看到表格就算成功。CSV最大的优势就是零依赖不需要安装任何NuGet包拼字符串就能干活。性能还特别高几十万行数据写CSV几乎没有压力。很多后端系统之间的数据交换也用CSV因为它简单、跨平台、任何编程语言都能处理。另外一个优势是体积小。同样的数据xlsx是压缩包CSV就是纯文本体积能差出好几倍。邮件附件、接口返回、老系统对接场景里CSV往往是最省事的载体。2.2 代码实现从一行数据到十万行数据最简单的CSV导出就是把字符串拼起来写到文件里。但真实项目里数据是对象列表我一般封装一个通用方法用反射把对象转成CSV行。using System.Text; public static void ExportToCsvT(IEnumerableT rows, string filePath) { var props typeof(T).GetProperties(); var sb new StringBuilder(); // 表头 sb.AppendLine(string.Join(,, props.Select(p p.Name))); // 数据行 foreach (var item in rows) { var values props.Select(p EscapeCsvField(p.GetValue(item))); sb.AppendLine(string.Join(,, values)); } // 注意UTF8Encoding(true) 会写入 BOMExcel 才能正确识别中文 File.WriteAllText(filePath, sb.ToString(), new UTF8Encoding(true)); } static string EscapeCsvField(object value) { if (value null) return string.Empty; var s Convert.ToString(value) ?? string.Empty; // 字段里如果包含逗号、双引号、换行就必须用双引号包裹内部双引号再转义 if (s.Contains(,) || s.Contains() || s.Contains(\n) || s.Contains(\r)) return \ s.Replace(\, \\) \; return s; }使用的时候直接传对象集合var data new ListPerson { new Person { Name 张三, Age 28, City 北京 }, new Person { Name 李四, Age 35, City 上海 } }; ExportToCsv(data, 员工信息.csv);如果数据量特别大几十万行甚至上百万行一次性把字符串全部拼进StringBuilder会占用不少内存。这时候改成StreamWriter逐行写入更稳内存占用基本恒定。using var writer new StreamWriter(large.csv, false, new UTF8Encoding(true)); writer.WriteLine(姓名,年龄,城市); for (int i 0; i 1000000; i) { writer.WriteLine($用户{i},{20 i % 30},城市{i % 50}); }一秒钟以内就能跑完效率非常高。这也是CSV在大数据量场景下依然有竞争力的原因。2.3 顺手把编码、引号、长数字三个坑填了第一个坑是中文乱码。CSV文件本身没有编码声明Excel打开时如果系统默认编码跟文件编码不一致中文就会变成一堆乱码。解决办法就是在文件头写入BOMByte Order Mark也就是代码里new UTF8Encoding(true)的真义。如果不加BOM用记事本打开正常Excel打开就乱。这个必须在写文件前就考虑好别等客户把文件发回来喊乱了再排查。第二个坑是字段里的逗号和引号。如果某个单元格的内容是“北京,上海”不加处理直接拼CSVExcel打开时会把“北京”和“上海”拆成两列数据就错位了。RFC 4180标准给出的处理方式是用双引号把整个字段包起来字段内部的引号再翻倍转义。上面代码里的EscapeCsvField就是干这个的建议任何正式项目都别省略这一步。第三个坑是长数字被Excel当成科学计数法显示。比如身份证号18位数字CSV里正常写Excel打开就成了1.23457E17看着像灵异事件。解决办法是在数字前面加一个Tab制表符或者写成123456789012345678这种公式形式。我常用的方案是Tab前缀兼容性好列出来还是文本格式static string ForceText(string value) { return \t value; }导出身份证这类字段时先过一遍ForceText问题立刻消失。3. 第二种HTML表格——被低估的“伪Excel”3.1 Excel能打开HTML这不是玩笑Excel从老早开始就能直接打开HTML文件HTML里的table表格会被Excel渲染成带边框的单元格。利用这一点我们可以在服务端生成一段HTML字符串保存成.xls扩展名用户拿到文件用Excel打开看到的就是一个规整的表格。这个思路放到今天看有点“野”但它在Web报表时代是实打实的常用方案而且现在用来应急依然好使。好处是零依赖不装任何包不依赖服务器装Excel代码量也很小几行就能出一个能看的表格文件。它还有一个明显优势HTML里的样式控制很灵活。想给表头加背景色、加粗、合并单元格直接用CSS和colspan就能实现语法大家都会不需要学库的API。3.2 代码实现表格字符串秒变xls先写一个方法从数据拼接HTML表格public static string BuildExcelHtmlT(IEnumerableT rows, string[] headers) { var props typeof(T).GetProperties(); var sb new StringBuilder(); sb.Append(!DOCTYPE htmlhtmlheadmeta charset\utf-8\/headbody); sb.Append(table border1 styleborder-collapse:collapse; font-family:Microsoft YaHei); // 表头 sb.Append(tr); foreach (var h in headers) sb.Append($th stylebackground-color:#DCE6F1; font-weight:bold; padding:4px{h}/th); sb.Append(/tr); // 数据行 foreach (var item in rows) { sb.Append(tr); foreach (var p in props) sb.Append($td stylepadding:4px{p.GetValue(item)}/td); sb.Append(/tr); } sb.Append(/table/body/html); return sb.ToString(); }在ASP.NET Core的控制器里直接返回这个内容作为文件下载响应[HttpGet] public IActionResult Export() { var data new ListPerson { /* 数据集合 */ }; var html BuildExcelHtml(data, new[] { 姓名, 年龄, 城市 }); var bytes Encoding.UTF8.GetBytes(html); return File(bytes, application/vnd.ms-excel, 员工信息.xls); }核心点在于application/vnd.ms-excel这个MIME类型浏览器收到之后会把内容当成Excel文件来处理弹出下载对话框。用户打开的时候虽然扩展名是.xls其实内部就是HTMLExcel自己会做解析。3.3 这种方案在什么场景下依然好用HTML表格方案最适合快速交付的场景内部管理系统的导出按钮领导要看数据格式差不多就行今天就要。这时候你不想引库、不想折腾部署环境用这套方案十分钟搞定。但也要诚实地说它的缺点。最大的问题是Excel打开时会弹“文件格式与扩展名不匹配”的警告因为文件内容既不是二进制xls也不是标准的OpenXML格式。虽然点“是”就能打开但首次接触的用户容易被吓到。另外它不支持多Sheet、公式、图表这些高级特性做复杂报表时能力明显不足。还有一个变种思路使用Excel 2003 XML格式XML Spreadsheet 2003。它比HTML更像Excel文件能定义行、列、单元格类型和公式打开时也不会触发扩展名警告。但语法复杂日常项目除非有硬性兼容要求否则我不太推荐优先投入。4. 第三种NPOI——老牌开源方案4.1 认识NPOI从POI移植来的老伙计NPOI是Apache POI项目的.NET版本最初是为了弥补.NET生态里操作Office文档能力的空白。它不依赖Office安装纯托管代码Windows和Linux都能跑在.NET Framework时代就是事实标准。只要搜C#操作Excel出来的教程十有八九是NPOI。NPOI支持读取和写入两种模式。读Excel也是它的强项很多老项目里解析上传的Excel文件用的就是NPOI。它内部区分两套APIHSSF处理.xls老格式XSSF处理.xlsx新格式。日常开发我基本只用XSSF因为xlsx是现在的主流。安装很简单dotnet add package NPOI设计上NPOI的API非常贴近Excel的物理结构Workbook工作簿下面是Sheet工作表Sheet下面是Row行Row下面是Cell单元格。理解了这个层级写代码基本不会迷路。4.2 核心代码XSSFWorkbook写xlsx下面这段代码生成一个带表头、日期、数值的xlsx文件覆盖了最常用的基础操作。using NPOI.SS.UserModel; using NPOI.XSSF.UserModel; public static void ExportWithNpoi(string filePath) { IWorkbook workbook new XSSFWorkbook(); ISheet sheet workbook.CreateSheet(员工信息); // 创建表头 IRow headerRow sheet.CreateRow(0); headerRow.CreateCell(0).SetCellValue(姓名); headerRow.CreateCell(1).SetCellValue(入职日期); headerRow.CreateCell(2).SetCellValue(薪资); // 数据 var data new List(string name, DateTime date, decimal salary) { (张三, new DateTime(2022, 3, 1), 12000m), (李四, new DateTime(2023, 7, 15), 9500m) }; for (int i 0; i data.Count; i) { IRow row sheet.CreateRow(i 1); row.CreateCell(0).SetCellValue(data[i].name); var dateCell row.CreateCell(1); dateCell.SetCellValue(data[i].date); dateCell.CellStyle.DataFormat workbook.CreateDataFormat().GetFormat(yyyy-mm-dd); row.CreateCell(2).SetCellValue((double)data[i].salary); } // 自动列宽 sheet.AutoSizeColumn(0); sheet.AutoSizeColumn(1); sheet.AutoSizeColumn(2); using FileStream fs new FileStream(filePath, FileMode.Create, FileAccess.Write); workbook.Write(fs); }注意两个细节日期单元格要单独设置DataFormat否则显示的是Excel的日期序列号比如45000.0这种用户会一头雾水NPOI里没有SaveAs方法核心就是workbook.Write(stream)写完记得释放FileStream。4.3 样式、公式、性能这几件事不能偷懒如果只是导出数据NPOI看着还挺简单。一旦要控制样式就得理解它的Font和CellStyle机制。IFont font workbook.CreateFont(); font.IsBold true; font.Color IndexedColors.White.Index; ICellStyle headerStyle workbook.CreateCellStyle(); headerStyle.SetFont(font); headerStyle.FillForegroundColor IndexedColors.DarkBlue.Index; headerStyle.FillPattern FillPattern.SolidForeground; headerRow.Cells[0].CellStyle headerStyle;这种写法自由度很高但代码量会明显增加。为了不让业务代码里到处是样式逻辑我一般把样式封装成一个小工具类比如workbook.CreateHeaderStyle()、workbook.CreateDateStyle()这样在主流程里调用就清爽很多。公式也支持比如想让一个单元格显示合计IRow summaryRow sheet.CreateRow(data.Count 1); summaryRow.CreateCell(0).SetCellValue(合计); var sumCell summaryRow.CreateCell(2); sumCell.SetCellFormula($SUM(C2:C{data.Count 1}));Excel打开后会自动计算结果不需要我们自己算。这个特性在做统计报表时非常好用。性能方面要诚实NPOI的XSSF是全内存模型数据量超过十几万行时内存占用会明显上升。如果只是几万行问题不大如果上百万行建议换MiniExcel或者CSV。另外AutoSizeColumn对中文宽度估算不准经常出现列宽太窄导致“###”显示不全的情况稳妥的办法是手动设置列宽sheet.SetColumnWidth(0, 20 * 256); // 20个字符宽度5. 第四种EPPlus——功能全面的现代选择5.1 EPPlus强在哪许可要注意什么EPPlus是基于OpenXML的封装库API设计比NPOI现代很多链式调用非常顺手。它专注.xlsx格式对Excel 2007的复杂特性支持很好图表、图片、数据透视表、条件格式、打印设置基本能做出来的Excel功能它都覆盖了。用起来最舒服的一点是单元格可以直接按坐标赋值ws.Cells[A1].Value 张三不需要先CreateRow再CreateCell。对写习惯了二维数组的人来说这个体验非常自然。但要注意许可变化。EPPlus从5.0版本开始变更了授权策略非商业用途免费商业用途需要购买授权。代码里如果不设置LicenseContext会直接抛异常。非商业场景加一行代码就能过ExcelPackage.LicenseContext LicenseContext.NonCommercial;商业项目如果已经买了授权把参数改成Commercial就行。纠结费用的话很多团队会选择停留在4.5版本LGPL许可但那样就用不上后续的功能更新这个权衡自己把握。安装dotnet add package EPPlus5.2 核心代码几行搞定复杂样式下面这段是EPPlus的基础导出示例顺带演示表头样式、日期格式、自动列宽。using OfficeOpenXml; using OfficeOpenXml.Style; public static void ExportWithEpplus(string filePath) { ExcelPackage.LicenseContext LicenseContext.NonCommercial; using var package new ExcelPackage(); var ws package.Workbook.Worksheets.Add(员工信息); // 表头 ws.Cells[A1].Value 姓名; ws.Cells[B1].Value 入职日期; ws.Cells[C1].Value 薪资; // 表头样式 using (var range ws.Cells[A1:C1]) { range.Style.Font.Bold true; range.Style.Font.Color.SetColor(Color.White); range.Style.Fill.PatternType ExcelFillStyle.Solid; range.Style.Fill.BackgroundColor.SetColor(Color.DarkBlue); } // 数据 ws.Cells[A2].Value 张三; ws.Cells[B2].Value new DateTime(2022, 3, 1); ws.Cells[B2].Style.Numberformat.Format yyyy-mm-dd; ws.Cells[C2].Value 12000; ws.Cells[A3].Value 李四; ws.Cells[B3].Value new DateTime(2023, 7, 15); ws.Cells[B3].Style.Numberformat.Format yyyy-mm-dd; ws.Cells[C3].Value 9500; // 自动列宽 ws.Cells[A1:C3].AutoFitColumns(); // 合计 ws.Cells[A4].Value 合计; ws.Cells[C4].Formula SUM(C2:C3); ws.Cells[C4].Style.Font.Bold true; package.SaveAs(new FileInfo(filePath)); }这里能看到EPPlus的两个特点一是用using块对单元格区域批量应用样式语法简洁二是公式直接用字符串赋值给Formula属性不用额外的方法调用。开发效率明显高于NPOI。5.3 图表、图片、透视表这类高级能力EPPlus真正拉开差距的是图表能力。在Excel里插入柱状图EPPlus只需要几行代码var chart ws.Drawings.AddChart(chart1, eChartType.ColumnClustered); chart.SetPosition(1, 0, 5, 0); // 放在第5行下方 chart.Series.Add(C2:C3, A2:A3); chart.Title.Text 员工薪资对比;图片就更简单一行就能把Logo塞进报表var pic ws.Drawings.AddPicture(logo, new FileInfo(logo.png)); pic.SetPosition(1, 0, 1, 0);数据透视表也是EPPlus的亮点用PivotTable对象可以动态创建透视分析。这些能力在面向管理层汇报的系统里非常实用老板希望Excel一打开就是图表齐全的分析报告用EPPlus实现速度最快。不过EPPlus也不是没有短板。它专注xlsx不支持读写旧的.xls格式大数据量场景下它在内存里构建整个文档模型性能和NPOI类似都扛不住超大文件。真到了百万行级别还是得让位给MiniExcel。6. 第五种MiniExcel——轻量高性能新选手6.1 从MiniExcel到MnExcelMiniExcel是这几年火起来的轻量级Excel库核心理念就八个字极简API极高性能。它不像NPOI那样堆砌复杂的Workbook/Sheet/Row/Cell概念而是直接让你传对象集合一行代码导出Excel。对业务系统来说这种抽象方式非常舒服。有个容易踩的坑MiniExcel从6.0版本开始因为商标原因更名为MnExcelNuGet包名也变了。所以现在新项目安装包的时候要注意dotnet add package MnExcel代码里的命名空间仍然是MiniExcelLibs老教程里的用法绝大多数可以直接照搬到新包。如果项目里已经引用了老版本的MiniExcel升级前要看一眼API变化尤其是包名引用处的using。6.2 核心代码一个方法导出和读取MiniExcel最爽的用法就是传对象集合直接保存。它内部通过反射读取对象属性自动生成表头再逐行写入。看代码using MiniExcelLibs; var data new[] { new { 姓名 张三, 入职日期 new DateTime(2022, 3, 1), 薪资 12000m }, new { 姓名 李四, 入职日期 new DateTime(2023, 7, 15), 薪资 9500m } }; MiniExcel.SaveAs(员工信息.xlsx, data);就这么简单一个文件就生成了。想自定义表头顺序传Dictionarystring, object列表即可var rows new ListDictionarystring, object { new() { [姓名] 张三, [薪资] 12000 }, new() { [姓名] 李四, [薪资] 9500 } }; MiniExcel.SaveAs(员工信息.xlsx, rows);读取Excel同样一行代码var rows MiniExcel.Query(员工信息.xlsx); foreach (var row in rows) { // row 是 IDictionarystring, object var name row[姓名]; }不需要手动遍历Sheet和Row直接得到字典集合。日常做Excel导入解析这个API可以说是所有方案里最省心的。6.3 大数据量下的流式写法和模板功能MiniExcel生来就是为了解决大数据量导出问题。它采用流式写入不把整个数据模型放进内存所以同样导出50万行数据NPOI可能内存飙到几百MB甚至GB级MiniExcel能控制在很低的范围。实测下来几十万行数据秒出这个体验在.NET生态里非常难得。配合流式写入可以处理更大规模的数据using var stream File.Create(large.xlsx); MiniExcel.SaveAs(stream, rows, printHeader: true);rows可以是迭代器数据边生成边写入不像List那样必须全部加载进内存。这个模式很适合从数据库分页读取一批写一批的场景。MiniExcel还有一个模板引擎适合套用固定报表格式。先在Excel里做一张模板单元格里写{{Name}}这种占位符然后填充数据var values new { Name 张三, Salary 12000m, Date DateTime.Now }; MiniExcel.SaveAsByTemplate(template.xlsx, output.xlsx, values);模板里的占位符会被自动替换成实际值。这种方案在生成“格式统一的月度报表”时特别高效模板交给业务同事编辑程序只管填数。缺点也是明显的图表、透视表、复杂样式这些高级能力不如EPPlus丰富。MiniExcel更适合“业务型导出”而不是“专业报表型导出”。7. 第六种COM互操作——知道但尽量别用7.1 原理调用本机安装的ExcelCOM互操作就是.NET通过COM接口直接操纵本机安装的Excel应用程序。你可以像人坐在电脑前操作Excel一样创建Application对象、添加Workbook、写入单元格、保存文件。这个方案是老教程的重灾区很多教程一上来就教你用Microsoft.Office.Interop.Excel操作。它能实现的自由度确实最高Excel客户端能做的操作理论上都能通过COM完成包括调用Excel内置函数、执行宏、设置复杂的打印格式。但它有个致命前提运行环境必须安装完整版的Microsoft Excel。在本地开发机上装个Office很普遍但服务器上为了跑一个导出功能去装Office后续维护就是无底洞。这点后面细说。先看看代码长什么样。安装包dotnet add package Microsoft.Office.Interop.Excel7.2 核心代码Interop操作Excelusing Excel Microsoft.Office.Interop.Excel; using System.Runtime.InteropServices; public static void ExportWithCom(string filePath) { var excelApp new Excel.Application { Visible false, DisplayAlerts false }; Excel.Workbook workbook null; Excel.Worksheet sheet null; try { workbook excelApp.Workbooks.Add(); sheet (Excel.Worksheet)workbook.Worksheets[1]; sheet.Name 员工信息; sheet.Cells[1, 1] 姓名; sheet.Cells[1, 2] 入职日期; sheet.Cells[2, 1] 张三; sheet.Cells[2, 2] new DateTime(2022, 3, 1); workbook.SaveAs(filePath, Excel.XlFileFormat.xlOpenXMLWorkbook); } finally { if (sheet ! null) Marshal.FinalReleaseComObject(sheet); if (workbook ! null) { workbook.Close(false); Marshal.FinalReleaseComObject(workbook); } excelApp.Quit(); Marshal.FinalReleaseComObject(excelApp); } }看着不算复杂但这段代码一旦跑起来问题往往出在你看不见的地方。Application对象、Workbook对象、Worksheet对象都是COM资源任何一个没释放干净都会在后台留下一个Excel进程。代码里虽然写了FinalReleaseComObject和Quit但真实环境里只要有一个对象引用没释放进程就赖着不走。7.3 为什么服务器场景要远离它我在一个部署了COM导出功能的生产环境里吃过亏服务器跑了两周内存持续上涨最后30多个Excel进程堆积在任务管理器里整个机器卡到需要重启。后来排查下来就是COM对象没有完全释放导致的而且因为导出操作在并发下容易踩中对象竞争问题更随机。微软官方其实不推荐在服务端做Office自动化原因是稳定性和可伸缩性都不可控。服务端往往用服务账号运行Excel进程以该账号身份启动文件目录权限、DCOM配置、32位与64位Office匹配问题都能单独排查一整天。还有并发问题同时有几个用户触发导出多个Excel进程同时工作资源消耗是成倍增长的。所以我给一个明确建议除非你是写本地个人小工具或者客户明确要求必须通过Excel宏来处理文件否则生产系统一律不要选COM方案。这个方案知道原理就行面试时能说清楚它为什么不靠谱反而显得有经验。8. 常见问题与排查技巧实录8.1 拿到手的中文全变乱码这个问题绝大多数发生在CSV场景。排查顺序先看编码CSV生成时有没有写入UTF-8 BOM如果用的是File.WriteAllText默认编码无BOMExcel会按系统本地编码猜测解析中文很容易乱。修复方式就是显式传入new UTF8Encoding(true)。Web下载场景的乱码还要检查HTTP响应是否把charset带上了。返回File时Content-Type要写成text/csv; charsetutf-8。如果用的是Response.Write务必在写内容之前设置Response.ContentEncoding Encoding.UTF8。NPOI和EPPlus生成的xlsx本质是XML压缩包自动携带编码信息一般不会出现中文乱码。真出现乱码先怀疑是不是中间层把字节流转成了字符串导致编码信息丢失。8.2 打开文件提示“文件格式与扩展名不匹配”这个警告几乎是HTML伪xls方案和CSV改名.xls方案的标配。因为文件内容不是标准Excel二进制或OpenXMLExcel打开时会拿扩展名和真实结构比对不一致就弹出警告。处理思路有两种。第一种是把扩展名改对CSV就用.csvHTML就保存成.html用户双击后用Excel或浏览器打开不会有警告。第二种是生成真正的xlsx用NPOI、EPPlus或MiniExcel生成标准格式文件问题自然消失。如果客户坚持要.xls扩展名又不想看警告那几乎没有完美解因为.xls是二进制格式HTML和CSV都冒充不了。最靠谱的路径就是换标准格式库。8.3 大数据量导出时内存飙高又卡死这是NPOI和EPPlus最容易踩的坑。它们都会在内存里完整构建工作簿对象数据越多内存占用越大。50万行数据导出一半突然OOM这种事故我见过不止一次。解决思路按优先级排第一选择是用MiniExcel流式写入或者用CSV分批次写文件第二选择是给NPOI/EPPlus场景做数据分批一个Sheet只写5万行拆成多个Sheet第三选择是限制导出数据量比如服务端分页查询提示用户分批导出。另外一个容易被忽视的问题导出操作里的查询结果集本身就在占用内存。如果DataTable一次性Load了百万行再交给Excel库Excel库还没开始工作内存就爆了。可以试试用流式读取数据库边读边写内存表现会好很多。8.4 导出后的数字变成了科学计数法身份证号、银行卡号这类长数字最容易触发这个现象。Excel对超过11位的纯数字会默认转科学计数法这不是库的问题是Excel本身的显示规则。CSV里处理我前面提过加Tab前缀强制转文本var value \t idCard;NPOI里把单元格数据格式设为文本ICellStyle textStyle workbook.CreateCellStyle(); textStyle.DataFormat workbook.CreateDataFormat().GetFormat(); cell.CellStyle textStyle; cell.SetCellValue(idCard); // 即使存的是字符串也要设置文本格式更保险EPPlus里同样操作cell.Value idCard; cell.Style.Numberformat.Format ;这样Excel打开时就会把单元格当文本显示不再自动转换。注意某些情况下即使设置了文本格式重新打开还是会变那就需要在数据前加一个不可见的撇号但那个方案对csv之外的场景不优雅最推荐的还是显式设置单元格格式。8.5 服务器上COM进程残留怎么清理如果历史代码已经用了COM而且出了进程残留应急办法是在任务管理器或命令行里杀掉Excel进程taskkill /F /IM EXCEL.EXE但这只是治标。治本的办法是从代码层面规范释放COM对象最稳妥的是写一个统一的释放方法并在finally块里执行。即便如此并发高了依然存在竞态风险。最彻底的做法就是趁早重构换成NPOI或MiniExcel方案彻底摆脱COM依赖。我做导出功能这些年最深的体会是方案本身没有绝对优劣只有合不合适。CSV能解决80%的简单导出MiniExcel能解决90%的业务导出剩下10%的复杂报表交给EPPlus。NPOI适合历史项目COM能躲多远躲多远HTML表格则是应急时候的好朋友。如果看完这篇你还在纠结那就从CSV开始写第一版交付给用户等需求真的复杂了再按这篇的思路换更重的库这条路我走过很多次基本不会错。