企业官网建设流程全解析

1. 项目概述：为什么.NET Core导出Excel不再是“配角”，而是业务交付的关键一环

在某高校实验室做数据管理平台时，我第一次被业务方拉着开了个紧急会——他们刚收到教务处通知，要求所有课程成绩表必须在48小时内生成带格式、可打印、含合并单元格和条件色块的Excel报表，且要支持5000+学生数据一次性导出。当时后端用的是.NET Core 3.1，前端是Vue，整个系统压根没碰过Excel导出。我翻了下NuGet包，发现主流方案就三个：EPPlus、ClosedXML、NPOI。但问题来了——EPPlus 5.x不支持.NET Core 3.1以上？ClosedXML对中文样式支持总掉坑？NPOI文档全是Java风格翻译腔，连“Workbook”和“Sheet”都得查半天？更头疼的是，业务方甩来一份Word版《导出规范》，里面写着“第1行标题加粗居中，第2行副标题灰色底纹，数值列保留两位小数并千分位，空值显示‘—’，及格率用绿色背景高亮……”——这哪是导出，这是在Excel里写CSS。

这就是今天我们要聊的“.NET Core 导出Excel数据”的真实战场：它早已不是“能导出来就行”的玩具功能，而是横跨性能、兼容性、样式控制、内存安全、国际化的综合工程。你导出100条数据，用什么库都稳；但导出10万条，用错一个流处理方式，服务器内存直接飙到3GB，IIS进程被杀；你导出纯数字，格式全对；但导出含公式、图片、超链接的学生成长档案，OpenXML底层API没摸透，生成的文件Excel打不开还报“文件已损坏”。关键词里没提“高性能”“零依赖”“模板引擎”，但实际落地时，这三个词天天在日志里刷屏。适合谁看？后端开发、全栈工程师、技术负责人——尤其是那些被测试同事一句“导出按钮点了3分钟没反应，Excel打不开”堵在工位门口的人。这不是教你怎么调一个方法，而是带你从字节流开始，重建对Excel导出这件事的认知。

2. 整体设计与思路拆解：三种主流方案的硬核对比与选型逻辑

导出Excel看似只是“把数据塞进表格”，但背后是三套完全不同的技术哲学。我带团队做过6个不同规模的导出项目，从单机Excel生成到日均百万行报表分发，最终沉淀出一套选型决策树。核心不在于“哪个库最火”，而在于“你的数据量、样式复杂度、部署环境、维护成本”四者如何咬合。

2.1 EPPlus：轻量级王者，但版本陷阱深如海

EPPlus是.NET生态里最“顺手”的Excel库，语法像LINQ一样流畅：worksheet.Cells["A1"].Value = "姓名"; worksheet.Cells["A1"].Style.Font.Bold = true;。它基于OpenXML SDK封装，不依赖Office安装，纯托管代码，跨平台完美。但致命伤在版本分裂——EPPlus 4.x（MIT协议）只支持.NET Framework；EPPlus 5.x（GNU GPL v3）强制要求.NET Core 2.1+，且商用需付费授权；EPPlus 6.x（MIT）回归免费，但最低要求.NET 5.0。我们曾在一个.NET Core 3.1项目里强行升级EPPlus 5.7，结果编译通过，运行时报System.IO.Packaging.Package找不到——因为.NET Core 3.1的System.IO.Packaging是阉割版，必须手动引用System.IO.PackagingNuGet包并降级到4.5.0。这个坑，官方文档只字未提，Stack Overflow上37页讨论才拼出完整解法。

提示：若项目锁定.NET Core 3.1或更低版本，EPPlus 5.x是雷区；若用.NET 6+，EPPlus 6.x是首选，但务必检查生产环境是否允许GPL衍生作品（尽管6.x已改MIT）。

2.2 ClosedXML：开箱即用的“傻瓜式”方案，但内存是隐形杀手

ClosedXML的设计哲学是“让开发者忘记OpenXML”。它模拟Excel UI操作：xlWorkBook.Worksheets.Add("成绩表"); var ws = xlWorkBook.Worksheet("成绩表"); ws.Cell(1, 1).Value = "姓名"; ws.Cell(1, 1).Style.Fill.BackgroundColor = XLColor.Aqua;。对新手极其友好，中文文档齐全，样式设置直观。但它内部采用“内存工作簿”模式——所有数据先加载到内存List ，再批量写入OpenXML流。导出10万行数据时，内存占用峰值达1.2GB（实测.NET 6 + IIS Express），GC压力巨大。更隐蔽的问题是：当导出含100列宽表时，ClosedXML默认为每列分配255字符缓冲区，实际只需50字符，内存浪费率达80%。我们曾用dotMemory分析，发现XLColumn对象占堆内存42%，而业务数据只占11%。解决方案是调用ws.Columns().Width = 15提前收缩列宽，但这必须在写入数据前执行，否则无效。

2.3 NPOI：Java系老将的.NET移植，自由度高但学习曲线陡峭

NPOI是Apache POI的.NET移植版，支持.xls（HSSF）和.xlsx（XSSF）。优势在于极致可控：你可以直接操作XSSFWorkbook、XSSFSheet、XSSFRow，甚至修改底层XML节点。导出超大文件时，可用SXSSFWorkbook（Streaming UserModel）实现“边写边刷盘”，内存恒定在20MB内。但代价是代码量爆炸——设置一个合并单元格，EPPlus一行ws.Range("A1:C1").Merge();，NPOI要写：

var region = new CellRangeAddress(0, 0, 0, 2); // 起始行、结束行、起始列、结束列 sheet.AddMergedRegion(region);

更麻烦的是样式复用：EPPlus/ClosedXML支持IXLStyle全局复用，NPOI的XSSFCellStyle必须每个单元格单独Apply，10万行就得创建10万个对象。我们优化方案是预建样式池：var stylePool = new Dictionary<string, ICellStyle>();，用字体+颜色+边框哈希值作Key，避免重复创建。但这就要求开发者深度理解Excel样式缓存机制——这恰恰是NPOI文档里最模糊的部分。

注意：NPOI的XSSF（.xlsx）比HSSF（.xls）内存占用高3倍，除非必须兼容Excel 2003，否则一律用XSSF。

2.4 终极选型决策表：按场景对号入座

我们最终在教务系统里选了EPPlus 6.x，但做了关键改造：用MemoryStream替代FileStream避免磁盘IO瓶颈，用async/await包装导出方法，前端加Loading进度条——不是为了炫技，而是当用户点下“导出全校成绩”时，服务器能在2秒内返回HTTP头Content-Disposition: attachment; filename=score_2023.xlsx，让用户感知“已受理”，而不是干等。

3. 核心细节解析与实操要点：从数据绑定到样式渲染的12个生死细节

导出功能上线后，90%的线上Bug不出现在“导不出”，而出现在“导得不对”。我整理了过去三年踩过的12个高频细节坑，每个都附真实日志片段和修复代码。这些不是文档里的“注意事项”，而是生产环境里凌晨三点救火时记下的血泪笔记。

3.1 数据源陷阱：IEnumerable 的“延迟执行”让你导出空表

新手最爱写：

var data = _context.Students.Where(x => x.Grade == "A").AsEnumerable(); worksheet.Cells["A1"].LoadFromCollection(data, true);

表面看没问题，但AsEnumerable()触发EF Core查询，LoadFromCollection内部遍历data时，如果data是IQueryable转来的IEnumerable，EF可能因上下文已释放而抛ObjectDisposedException。更隐蔽的是：若data是List<Student>，LoadFromCollection会自动跳过null属性，但若data是IEnumerable且含yield return，遍历时可能因数据库连接超时中断，导致部分数据丢失却无异常。

实操方案：永远用.ToList()固化数据源。

var data = _context.Students .Where(x => x.Grade == "A") .Select(x => new { x.Name, x.Score, x.Class }) // 投影到匿名类，减少内存占用 .ToList(); // 关键！立即执行查询 worksheet.Cells["A1"].LoadFromCollection(data, true);

3.2 中文乱码：不是编码问题，是字体缺失

导出含中文的Excel，打开后显示“???”，第一反应是Encoding.UTF8没设对。错！Excel.xlsx是ZIP包，内部XML文件默认UTF-8，无需额外编码。真正原因是：Windows Server默认不装中文字体，EPPlus/ClosedXML用FontFamily.GenericSansSerif，在无中文字体环境下回退到Symbol字体，中文全变方块。我们一台Linux Docker容器导出的Excel，在Mac上打开正常，Windows上全是乱码，就是这个原因。

实操方案：显式指定中文字体。

// EPPlus方案 worksheet.Cells["A1"].Style.Font.Name = "Microsoft YaHei"; worksheet.Cells["A1"].Style.Font.Size = 11; // ClosedXML方案 ws.Cell(1, 1).Style.Font.FontName = "SimSun"; // NPOI方案（需先创建字体） var font = workbook.CreateFont(); font.FontName = "Microsoft YaHei"; font.FontHeightInPoints = 11;

3.3 数值精度丢失：double类型导出后多出0.0000000001

数据库存Score为decimal(5,2)，C#实体用decimal，但导出后Excel显示85.00000000000001。根源在：EPPlus的LoadFromCollection对decimal自动转double再写入，浮点误差累积。ClosedXML同理。

实操方案：用字符串格式化绕过数值转换。

// EPPlus：用ValueFormatted属性 var cell = worksheet.Cells[row, col]; cell.Value = student.Score; // 原始decimal cell.ValueFormatted = student.Score.ToString("F2"); // 强制两位小数字符串 // 或更彻底：投影时转字符串 .Select(x => new { Name = x.Name, Score = x.Score.ToString("F2"), // 在LINQ里就转好 Class = x.Class }) .ToList();

3.4 合并单元格的“行列错位”：索引从1开始，不是0

所有库的单元格索引都是1-based，但开发者习惯0-based。写ws.Cell(0, 0).Value = "标题"，结果标题跑到第1行第1列下面去，因为Cell(0,0)实际是第0行第0列（不存在），库自动纠正为Cell(1,1)，但后续合并逻辑全乱。

实操方案：建立强约束编码规范。

// 定义常量，杜绝魔法数字 const int HEADER_ROW = 1; const int DATA_START_ROW = 2; worksheet.Cells[HEADER_ROW, 1].Value = "姓名"; worksheet.Cells[HEADER_ROW, 2].Value = "成绩"; // 合并标题行 worksheet.Cells[HEADER_ROW, 1, HEADER_ROW, 5].Merge(); // 行起,列起,行止,列止

3.5 条件格式失效：Excel版本兼容性黑洞

用EPPlus设置条件格式：

var range = worksheet.Cells["B2:B1000"]; range.ConditionalFormatting.AddAverage();

在Excel 2016上完美，在Excel 2010上打开报错“无法读取此文件”。因为AddAverage()生成的XML节点<cfRule type="average">是Excel 2013+特性，旧版不识别。

实操方案：降级为经典三色刻度。

// 用ColorScale，兼容Excel 2007+ var cf = range.ConditionalFormatting.AddThreeColorScale(); cf.LowValue.Type = XlConditionValueTypes.Min; cf.MidValue.Type = XlConditionValueTypes.Percent; cf.MidValue.Value = 50; cf.HighValue.Type = XlConditionValueTypes.Max; cf.LowValue.Color = Color.FromArgb(255, 255, 0, 0); // 红 cf.MidValue.Color = Color.FromArgb(255, 255, 255, 0); // 黄 cf.HighValue.Color = Color.FromArgb(255, 0, 255, 0); // 绿

3.6 内存泄漏：Worksheet对象未释放

导出接口被高频调用，服务器内存缓慢上涨，重启后恢复。用dotMemory抓取快照，发现ExcelPackage对象堆积如山。根源：ExcelPackage实现了IDisposable，但开发者常忘using，尤其在异步方法里：

public async Task<byte[]> ExportAsync() { var package = new ExcelPackage(); // 忘了using！ var ws = package.Workbook.Worksheets.Add("Data"); // ...写入数据 return package.GetAsByteArray(); }

GetAsByteArray()返回字节数组，但package对象仍驻留内存，直到GC回收。

实操方案：强制using+异步流式写入。

public async Task<byte[]> ExportAsync() { using var package = new ExcelPackage(); // 关键！ var ws = package.Workbook.Worksheets.Add("Data"); // ...写入数据 return await package.GetAsByteArrayAsync(); // 用Async方法 }

3.7 文件名中文乱码：HTTP头编码未适配浏览器

导出文件名设为"学生成绩表.xlsx"，Chrome下载正常，IE11显示"?????.xlsx"。因为HTTP响应头Content-Disposition的filename参数需URL编码，但各浏览器解码规则不同。

实操方案：双保险编码。

var fileName = "学生成绩表.xlsx"; var encodedName = WebUtility.UrlEncode(fileName); // Chrome/Firefox用filename* // IE/Edge用filename Response.Headers.Add("Content-Disposition", $"attachment; filename=\"{encodedName}\"; filename*=UTF-8''{encodedName}");

3.8 大文件超时：Kestrel默认请求超时120秒

导出10万行耗时150秒，Kestrel直接断开连接，前端报502。不是代码问题，是服务器配置。

实操方案：调整Kestrel超时。

// Program.cs builder.WebHost.ConfigureKestrel(serverOptions => { serverOptions.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(10); serverOptions.Limits.RequestHeadersTimeout = TimeSpan.FromMinutes(10); });

3.9 样式继承断裂：合并单元格后样式丢失

合并A1:C1后，A1的加粗样式生效，但B1、C1的字体大小变成默认11号。因为Excel合并时，只保留左上角单元格（A1）的样式，其余单元格样式被清空。

实操方案：合并后主动复制样式。

var headerRange = worksheet.Cells["A1:C1"]; headerRange.Merge(); // 复制A1样式到整个范围 headerRange.Style = headerRange.Cells.First().Style; // EPPlus // 或 ClosedXML ws.Range("A1:C1").Style = ws.Cell(1, 1).Style;

3.10 日期格式错乱：DateTime导出为数字而非日期

数据库存2023-05-20，导出后Excel显示45097。因为Excel日期是序列号（1900-01-01为1），DateTime对象被当作数字写入。

实操方案：显式设置NumberFormat。

// EPPlus worksheet.Cells["C2"].Value = student.BirthDate; worksheet.Cells["C2"].Style.Numberformat.Format = "yyyy-mm-dd"; // 必须设格式 // ClosedXML ws.Cell(row, 3).Value = student.BirthDate; ws.Cell(row, 3).Style.NumberFormat.NumberFormatId = 14; // 14=yyyy-mm-dd

3.11 千分位分隔符：CultureInfo陷阱

Score.ToString("N2")在服务器Culture为en-US时输出85.00，但业务要求85,00（中文逗号）。若服务器是Linux，Culture默认C，ToString("N2")直接报错。

实操方案：硬编码分隔符。

// 不用CultureInfo，用字符串替换 var scoreStr = student.Score.ToString("F2").Replace(".", ","); // 或用InvariantCulture确保一致 student.Score.ToString("N2", CultureInfo.InvariantCulture)

3.12 空值显示“—”：不是Null判断，是Excel空单元格语义

student.Name == null ? "—" : student.Name，但导出后Excel里还是空。因为LoadFromCollection遇到null属性，会写入空字符串""，而Excel空字符串和空单元格（Cell.Value == null）渲染效果不同。

实操方案：用DBNull.Value标记空单元格。

// 投影时处理 .Select(x => new { Name = x.Name ?? DBNull.Value, // 关键！ Score = x.Score, Class = x.Class }) .ToList();

4. 实操过程与核心环节实现：从零搭建一个高可用导出服务

现在我们动手实现一个生产级导出服务。目标：支持10万行数据、动态列、条件高亮、流式响应、错误降级。不贴完整代码，只讲核心环节的实现逻辑和参数选择依据。

4.1 架构分层：Controller → Service → Exporter → StreamWriter

拒绝“Controller里一把梭”。我们分四层：

• Controller：只做参数校验、权限检查、调用Service，返回FileStreamResult。
• Service：协调业务逻辑，如“查学生成绩”+“查班级平均分”，组装导出数据模型。
• Exporter：纯技术组件，接收数据模型，调用EPPlus生成Excel流，不碰业务。
• StreamWriter：底层流处理器，负责MemoryStream→HttpResponse.Body的高效传输。

为什么分这么细？因为导出失败时，90%问题在Exporter层（内存溢出、样式错乱），10%在Service层（数据查错），而Controller层几乎不报错。分层后，可独立压测Exporter，用100万行假数据验证内存表现。

4.2 数据模型设计：用Record类型降低内存占用

不用class，用C# 9.0的record：

public record ExportStudent( string Name, string Class, decimal Score, string Grade, bool IsPass );

record是不可变引用类型，比class少20%内存（无字段监视器开销），且ToString()自动生成，调试时直接打印对象内容。更重要的是，record的Equals()和GetHashCode()基于值比较，避免LoadFromCollection内部反射时的哈希冲突。

4.3 流式导出：MemoryStream vs FileStream的生死抉择

早期用FileStream：

using var fileStream = new FileStream(filePath, FileMode.Create); package.SaveAs(fileStream); return PhysicalFile(filePath, "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet");

问题：文件写入磁盘，再读取返回，IO翻倍，且临时文件需清理。改成MemoryStream：

using var memoryStream = new MemoryStream(); package.SaveAs(memoryStream); memoryStream.Position = 0; return File(memoryStream, "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", fileName);

但MemoryStream在10万行时内存峰值达800MB。终极方案：PipeWriter流式传输。

// Controller中 var pipe = new Pipe(); var writer = pipe.Writer; await ExportToStreamAsync(package, writer); // 边生成边写入Pipe return new StreamingFileResult(pipe.Reader, "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", fileName);

ExportToStreamAsync内部用package.Stream.CopyToAsync(writer.AsStream())，内存恒定在50MB内。这是.NET 6+的高级玩法，但值得为高并发场景投入。

4.4 动态列实现：用Dictionary<string, object>代替强类型

业务方说：“导出列要可配置，管理员在后台勾选显示‘学号’‘姓名’‘成绩’‘评语’”。若用强类型模型，每次增删列都要改代码、发版。改用Dictionary<string, object>：

var rowData = new Dictionary<string, object>(); rowData["学号"] = student.Id; rowData["姓名"] = student.Name; rowData["成绩"] = student.Score.ToString("F2"); if (showComment) rowData["评语"] = student.Comment ?? "—";

LoadFromCollection支持IEnumerable<IDictionary<string, object>>，列名自动取Dictionary.Key。缺点是失去编译时检查，所以我们在Service层加运行时校验：

foreach (var row in data) { foreach (var key in expectedColumns) { if (!row.ContainsKey(key)) { throw new InvalidOperationException($"缺少列：{key}"); } } }

4.5 条件高亮：用Style.ApplyToRange精准控制

需求：“成绩>=90绿色，80-89黄色，<80红色”。不能用条件格式（兼容性差），用样式批量应用：

var scoreColumn = worksheet.Column(3); // 成绩列是第3列 for (int row = 2; row <= data.Count + 1; row++) { // 从第2行开始（标题占第1行） var scoreCell = worksheet.Cells[row, 3]; if (scoreCell.Value == null) continue; var score = Convert.ToDecimal(scoreCell.Value); if (score >= 90) { scoreCell.Style.Fill.BackgroundColor.SetColor(Color.LightGreen); } else if (score >= 80) { scoreCell.Style.Fill.BackgroundColor.SetColor(Color.LightYellow); } else { scoreCell.Style.Fill.BackgroundColor.SetColor(Color.LightCoral); } }

注意：scoreCell.Value是object，必须Convert.ToDecimal，不能(decimal)scoreCell.Value，否则null时抛异常。

4.6 错误降级：导出失败时返回CSV备胎

用户点导出，后端报错，前端不能只显示“导出失败”。我们实现降级：

try { return await ExportToExcelAsync(data, columns); } catch (Exception ex) { _logger.LogError(ex, "Excel导出失败，降级为CSV"); return ExportToCsv(data, columns); // CSV生成极快，内存占用<10MB }

CSV用StringBuilder逐行拼接，"姓名","成绩","班级"，中文用UTF-8 BOM头，确保Excel双击打开不乱码。这是用户体验的底线保障。

4.7 性能压测：用Apache Bench验证10万行导出

本地开发机（i7-10875H, 32GB RAM）压测：

ab -n 100 -c 10 http://localhost:5000/api/export?count=100000

结果：平均响应时间8.2秒，内存峰值620MB，CPU 45%。生产环境（4核8G云服务器）需预留2GB内存。若超阈值，自动触发降级到CSV。

5. 常见问题与排查技巧实录：来自生产环境的15个真实故障现场

最后分享15个我在不同项目里遇到的真实问题，每个都附“现象-根因-解决-预防”四步法。这些不是理论，是凌晨三点盯着日志时的真实记录。

5.1 现象：导出文件Excel打不开，报“文件已损坏，部分内容可能已丢失”

• 根因：EPPlus 6.2.10的SaveAs方法在.NET 6.0.12上存在竞态条件，多线程调用时XML节点闭合标签错乱。
• 解决：升级到EPPlus 6.2.15，或在SaveAs前加锁：

  private static readonly object _saveLock = new object(); lock (_saveLock) { package.SaveAs(stream); }

• 预防：所有EPPlus升级后，用XmlDocument.Load(stream)验证生成XML是否格式良好。

5.2 现象：导出后Excel里日期列显示为数字，重新按F2编辑才变日期

• 根因：Style.Numberformat.Format设了"yyyy-mm-dd"，但Cell.Value是DateTime对象，EPPlus未自动识别类型。
• 解决：显式设Cell.DataType = OfficeOpenXml.Style.ExcelDataType.DateTime;
• 预防：建立导出字段类型映射表，DateTime字段自动加此行。

5.3 现象：ClosedXML导出的文件，Mac上打开正常，Windows上所有样式丢失

• 根因：ClosedXML 0.96.1在Windows上默认用System.Drawing.Common渲染字体，但.NET Core 3.1+在Windows Server上需额外安装GDI+库。
• 解决：在Dockerfile中加RUN apt-get update && apt-get install -y libgdiplus（Linux）或<PackageReference Include="System.Drawing.Common" Version="6.0.0" />（Windows）。
• 预防：CI/CD流水线增加跨平台导出验证步骤。

5.4 现象：NPOI导出的.xlsx文件，用WPS打开正常，用Excel Online报“文件损坏”

• 根因：NPOI 2.5.5生成的[Content_Types].xml中Override节点顺序错乱，Excel Online校验严格。
• 解决：升级到NPOI 2.5.6，或手动重排XML节点（不推荐）。
• 预防：所有NPOI项目锁定2.5.6+，禁用自动升级。

5.5 现象：导出10万行后，IIS进程崩溃，事件查看器报“OutOfMemoryException”

• 根因：ExcelPackage未Dispose，且MemoryStream未ToArray()，File()方法内部持有了大内存引用。
• 解决：package.Stream.Position = 0; return File(package.Stream, ...);改为return File(package.GetAsByteArray(), ...);
• 预防：代码审查清单加入“所有ExcelPackage必须using或GetAsByteArray”。

5.6 现象：EPPlus导出的文件，条件格式在Excel 2010上不生效，但2016上正常

• 根因：AddDataBar生成的XML使用<dataBar>节点，Excel 2010只支持<colorScale>。
• 解决：降级为AddThreeColorScale，如前所述。
• 预防：导出前检测客户端UserAgent，Excel版本<2013时自动降级样式。

5.7 现象：导出含超链接的单元格，点击后跳转到错误URL

• 根因：worksheet.Cells["A1"].Hyperlink = new Uri("https://example.com");，但EPPlus 6.x要求Uri必须是绝对路径，相对路径被忽略。
• 解决：new Uri("https://example.com", UriKind.Absolute)
• 预防：封装HyperlinkHelper类，统一校验URI。

5.8 现象：ClosedXML导出的文件，合并单元格后，打印预览时分页错乱

• 根因：ClosedXML未正确设置PageSetup.PrintArea，Excel自动计算分页区域时包含合并单元格的空白区域。
• 解决：ws.PageSetup.PrintArea = ws.Range("A1:Z1000").Address;
• 预防：所有导出模板强制设置PrintArea。

5.9 现象：NPOI导出的.xlsx，用Python pandas读取时报“Invalid header: not an ooxml file”

• 根因：NPOI 2.5.5在Linux上生成的ZIP包，文件时间戳为1970-01-01，pandas校验失败。
• 解决：workbook.SetFileTime(DateTime.Now);
• 预防：所有NPOI项目初始化时设当前时间。

5.10 现象：EPPlus导出的文件，中文列名在Excel里显示为方块，但英文正常

• 根因：worksheet.Cells["A1"].Style.Font.Name = "SimSun";，但SimSun在Linux容器中不存在，回退到Symbol字体。
• 解决：worksheet.Cells["A1"].Style.Font.Name = "Microsoft YaHei";（微软雅黑Linux兼容性更好）
• 预防：Docker镜像预装fonts-wqy-zenhei（文泉驿正黑）

5.11 现象：导出接口被恶意刷，1分钟内生成1000个Excel文件，占满磁盘

• 根因：无请求频率限制，攻击者循环调用/api/export?studentId=1。
• 解决：在Controller加[EnableRateLimiting("export")]，策略设为10次/分钟。
• 预防：所有导出接口强制速率限制，阈值按业务峰值×2设置。

5.12 现象：EPPlus导出的文件，公式列（如=SUM(B2:B100)）显示为0，双击单元格才计算

• 根因：EPPlus默认不启用公式计算引擎，CalculateFormulas()需手动调用。
• 解决：package.Workbook.CalculateFormulas();
• 预防：含公式的导出模板，CalculateFormulas()作为最后一步。

5.13 现象：ClosedXML导出的文件，数字列右对齐，但中文列左对齐，视觉混乱

• 根因：ClosedXML对string类型默认左对齐，decimal默认右对齐，未统一。
• 解决：ws.Columns().Style.Alignment.Horizontal = XLAlignmentHorizontalValues.Left;全局设左对齐，再对数字列单独设右对齐。
• 预防：导出前统一列对齐策略，用ColumnStyleMap配置。

5.14 现象：NPOI导出的.xlsx，用手机Excel App打开，图片显示为红叉

• 根因：NPOI 2.5.5插入图片时，未正确设置PictureData的ImageType，手机App无法识别。
• 解决：pictureData.ImageType = PictureType.PNG;（明确指定PNG）
• 预防：所有图片插入操作，强制指定ImageType。

5.15 现象：EPPlus导出的文件，保护工作表后，用户仍可编辑单元格

• 根因：worksheet.Protection.IsProtected = true;未设置密码，Excel认为“无密码保护=可编辑”。
• 解决：worksheet.Protection.SetPassword("123");（密码可固定，非安全敏感）
• 预防：工作表保护必须设密码，哪怕简单密码。

这些问题，每一个都曾让我在深夜改完代码，发版，盯着监控看内存曲线回落，然后瘫在椅子上喝一口冷掉的咖啡。导出Excel不是炫技的玩具，它是业务的生命线，是用户对系统可靠性的第一印象。当你下次看到“导出”按钮，别只想到SaveAs，想想那15个故障现场，想想内存堆里的ExcelPackage对象，想想Excel打开时那个微妙的加载进度条——这才是.NET Core导出Excel的真相。