用 EPPlus 的 LoadFromCollection 会爆内存，因其全量加载数据到内存再逐单元格写入；应改用 OpenXmlWriter 流式生成或分块手动写入 ExcelPackage。
用 EPPlus 的 LoadFromCollection 会爆内存？别这么用
直接把上百万条数据塞进 List 再调用 LoadFromCollection，本质是全量加载到内存再逐单元格写入，GC 压力大、峰值内存轻松破 2GB。这不是 EPPlus 的问题，是你没走流式路径。
正确做法是绕过集合一次性加载，改用 ExcelPackage + ExcelWorksheet.Cells[row, col] 手动控制行写入节奏，配合 rowIndex 自增和 Save() 前不触发全量渲染。
- 务必禁用
worksheet.Cells.AutoFitColumns()和worksheet.Protection.IsProtected = true等触发全表扫描的操作 - 写完 10000 行后主动调用
package.Stream.Position = 0（非必需），但更关键的是避免提前访问worksheet.Dimension - 字段类型尽量用
string或原始值，别传含复杂ToString()逻辑的对象——每次取值都可能触发副作用
StreamWriter 不行，但 OpenXmlWriter 可以真流式
StreamWriter 只能写 CSV，写不了 Excel（.xlsx 是 ZIP+XML 结构）。真正支持边生成边写入的底层 API 是 OpenXmlWriter，它允许你按 Open XML 标准逐段输出
缺点是编码成本高，需手动处理共享字符串表（SharedStringTablePart）、数字格式、合并单元格等。如果你导出结构固定、无公式、无样式，推荐封装一个轻量 ExcelRowWriter 类：
- 初始化时创建
SpreadsheetDocument并获取WorkbookPart和WorksheetPart - 每写一行，用
OpenXmlWriter.Create(worksheetPart.GetStream(FileMode.Create))追加 - 字符串必须先注册进
SharedStringTablePart，重复值复用索引，否则文件体积暴增
为什么 DataTable + LoadFromDataTable 也不安全？
表面看 LoadFromDataTable 接收 DataTable 引用，但 EPPlus 内部仍会遍历所有 DataRow 并缓存每个单元格的样式/类型信息。当 DataTable.Rows.Count > 50000，内部字典扩容和装箱开销就会显著抬升内存占用。
更隐蔽的问题是：如果 DataTable 的列含 DBNull.Value，EPPlus 默认转成空字符串并计入共享字符串表——导致本可复用的空值被当成独立字符串条目，共享表膨胀数倍。
- 导出前先调用
dataTable.AcceptChanges()，减少行状态追踪开销 - 用
dataTable.AsEnumerable().Take(10000)分批处理，每批新建ExcelWorksheet，写完Dispose()对应worksheet - 避免在
DataTable中混用DateTime和string存同一列，类型推断失败会导致整列降级为文本且无法设置 NumberFormat
分块写入时如何避免 Excel 打开报“文件已损坏”？
核心是不能只写 WorkbookPart → WorksheetPart → SharedStringTablePart）和结尾标签闭合。常见错误是分块后忘了补 或漏写 [Content_Types].xml 中的部件声明。
安全做法是：用 ExcelPackage 创建空模板（含最小必要结构），然后用 OpenXmlWriter 替换其中 WorksheetPart 的
- 不要手动拼接 XML 字符串，用
OpenXmlWriter保证命名空间和缩进合法 - 写完所有行后，必须显式调用
worksheetPart.Worksheet.Save()，否则sheetData可能未刷新到底层流 - 若导出含多工作表，每个
WorksheetPart需独立处理，共用的SharedStringTablePart必须在所有写入完成后统一提交
实际最易忽略的点：共享字符串表不是线程安全的，多线程并发写入时若未加锁或未预分配索引，会出现字符串重复注册或索引错位，导致 Excel 打开后显示 #VALUE! 或乱码。单线程分块写入仍是当前最稳方案。
