简介：面向使用 DevExpress WinForm 的.NET 开发人员，这份资源提供了一套通用控件导出 Excel 的完整解决方案。核心解决了 GridControl 自带导出方法不支持图片、多表头难以导出，以及 PivotGridControl 导出时自动分组等问题，真正实现所见即所得的导出效果；同时支持多个控件一同导出到同一个 Excel，并可将不同控件分别放置在独立工作簿中，满足报表合并与分页输出的实际需求。资源共 179 个文件，以 110 个 dll 运行库、10 个 cs 源码、3 个 exe 可执行程序为主，另含 sln/csproj 解决方案文件、config 配置、png 效果截图等；压缩包约 35.09MB，属于可直接打开编译的完整工程，便于对照调试与二次改造。演示工程中配有 Form1 示例窗体及相关资源文件，可直观查看多控件导出、工作簿分拆的完整调用方式。目前已有 1022 人学习下载，开发者可从源码中提取导出逻辑、异常处理与工作簿分拆思路，快速集成到自己的业务模块中，大幅减少报表导出功能的重复踩坑。
1. 一个偷懒需求：让 DevExpress 控件直接变成 Excel 文件
做 WinForm 报表导出时，最烦的不是写导出逻辑，而是每个界面都要重复来一遍。某次给某图像处理 Demo 加导出功能，界面上一张主表、一张统计图、一个树列表，需求是把这三个控件分别放进同一个 Excel 的不同工作表里。当时第一反应是写三份循环代码，被某导师拦住——说 DevExpress 的控件本身都带导出能力，问题只是怎么组合调用。做完之后发现确实是这样，用对入口方法，几行就能把布局和样式一起带走。
这篇笔记想拆的就是这套思路：把 GridView、ChartControl、TreeList 这些常见控件统一接进一个导出方法，支持把多个控件分工作簿写进同一个 xlsx。适合正在做 WinForm 报表、被到处抄导出代码且每次都得调半天的开发者，也适合想把导出逻辑收敛到一个公共类里的维护者。
2. 先把导出路线定下来：三种常见方案和 DevExpress 为什么值得用
2.1 自己写 NPOI 循环和用自带导出工具的差别
WinForm 里导出 Excel，最常看到的是 NPOI 方案。自己建 HSSFWorkbook、创建 Sheet、循环给单元格赋值，能精确控制每个单元格，但代价是工作量全在你身上。控件里有什么列、列宽多少、合并单元格在哪、图片怎么放，都得手写。这种做法对固定报表还行，但界面只要一变，导出的循环就跟着改，维护成本高。
另一条路是 DevExpress 自带的导出。GridView 有 ExportToXlsx，ChartControl 有 ExportToXlsx，TreeList 也有 ExportToXlsx。它们的共同点是“所见即所得”——界面长什么样，导出来基本就什么样，列宽、样式、分组、图片都会带过去。代价是控制粒度比 NPOI 粗，定制单元格内容时不如自己写顺手。
实际项目里我的判断标准就一句话：数据量大、格式要求自由发挥的报表用 NPOI，控件多、界面复杂的内部工具优先用自带导出。因为自带导出不需要重建视图，代码量少一半，而且用户拿到手的 Excel 跟他屏幕上看到的对得上。
2.2 多个工作簿拆分的两种实现思路
需求里说的“多个控件分工作簿导出”，核心是两个问题：第一，每个控件导出到独立工作表；第二，所有这些工作表要落在同一个文件里。
第一种思路是分开导出再合并。先让每个控件各自导出一个 xlsx，再用 NPOI 或 OpenXML 把多个文件的工作表合并到一个文件。这个做法的坑在于格式丢失严重，DevExpress 导出时写的列宽、样式、图片到了合并环节经常变形，甚至直接丢。后来我基本不推荐这条路，除非对格式要求极低。
第二种思路是用 DevExpress 的 XlsxExporter 把多个导出结果写入同一个工作簿。常见做法是先导出第一个控件作为主文档，之后用工作表级别的复制或直接通过 Spreadsheet 控件组合多个导出流。我自己用得最多的是先导出到一个内存流，再把这个流里每个工作表拆分或重命名，逐层组装。
2.3 为什么统一封装一个通用导出方法
控件一多，最容易出问题的是到处粘贴导出代码。主窗体写一段，子窗体复制一份，改个参数改漏了，导出就翻车。所以封装一个公共方法是必然选择，核心是让调用方只传控件列表和文件路径，里面自己去判断控件类型并调用各自的导出入口。
封装的好处还有一个，方便统一处理导出选项。比如导出的 Excel 需不需要自适应列宽、单元格文字要不要换行、Sheet 名要不要规避特殊字符，这些散落在各处的逻辑收进一个类里，以后改一处就好。
封装类我一般会提供一个入口方法，参数是控件数组加导出路径，底层对每个控件做类型分发。这样新增一种控件类型时，只需要在公共类里加一个分支，不用动业务界面。
public static void ExportControlsToExcel(Control[] controls, string filePath) { using (var stream = new FileStream(filePath, FileMode.Create)) { int sheetIndex = 0; foreach (var control in controls) { if (control is GridControl grid) { var view = grid.MainView as GridView; view.ExportToXlsx(stream, new XlsxExportOptionsEx { ExportType = ExportType.WYSIWYG }); } else if (control is ChartControl chart) { chart.ExportToXlsx(stream, new XlsxExportOptionsEx { ExportType = ExportType.WYSIWYG }); } else if (control is TreeList tree) { tree.ExportToXlsx(stream, new XlsxExportOptionsEx { ExportType = ExportType.WYSIWYG }); } } } }这段代码的问题在于，直接把多个控件导进同一个 FileStream，DevExpress 的导出方法会互相覆盖，最终文件只有一个工作表。真正能用的写法是先导出到内存流，再按工作表维度拆分合并。这也是我刚做这个功能时踩的第一个坑，后面避坑章会细说。
正确做法是用 DevExpress 的 Spreadsheet 文档对象，逐个打开导出结果，把工作表复制到一个统一的工作簿里。这里的关键点是每个控件先单独导出成一个小 xlsx 流，再用 Spreadsheet 合并。代码量不大，但思路必须转过来“先独立后合并”。
3. 动手写一个可用的通用导出类：让 GridView、ChartControl、TreeList 各归其位
3.1 使用 Spreadsheet 组件管理多个工作簿
要真正支术多工作簿合并，DevExpress 提供的核心组件是 SpreadsheetControl，配合它的 Document 对象可以做工作表的复制、重命名、排序。它就像一个在内存中运行的 Excel 编辑器，打开导出文件、读取工作表、跨文件复制，都是通过 Document 的 API 完成。
底层逻辑不复杂：用 SpreadsheetControl 创建一个空的工作簿作为目标文档，然后循环打开每个控件的导出文件，把里面的工作表逐个复制到目标文档里，最后把目标文档保存成 xlsx。这样做的好处是整个过程中格式不会丢，因为复制的是 DevExpress 内部的对象模型，而不是把单元格坐标重新计算一遍。
我一般会把合并逻辑写成独立方法，输入是一个 List ，代表每个控件单独导出的 xlsx 流；输出是最终文件路径。中间用 SpreadsheetControl 实例承载合并过程，完成后释放资源。
public static void MergeExcelStreams(List<MemoryStream> streams, string outputPath) { using (var spreadsheet = new SpreadsheetControl()) { spreadsheet.CreateNewDocument(); var targetDoc = spreadsheet.Document; foreach (var stream in streams) { stream.Position = 0; using (var sourceDoc = spreadsheet.CreateNewDocument()) { sourceDoc.LoadDocument(stream, DevExpress.Spreadsheet.DocumentFormat.Xlsx); foreach (var sheet in sourceDoc.Worksheets) { var targetSheet = targetDoc.Worksheets.Add(); targetSheet.CopyFrom(sheet); } } } targetDoc.SaveDocument(outputPath, DevExpress.Spreadsheet.DocumentFormat.Xlsx); } }这里两层 CreateNewDocument 很容易让人绕晕，实际上第一次是整个目标文档，第二次是打开每个待合并的小文件。小文件用完必须释放，否则内存里挂一堆文档对象，导出几个控件后内存占用会明显涨起来。
CopyFrom 方法会把原工作表的样式、列宽、合并单元格一起复制到目标工作表，比逐单元格复制省心得多。这套 API 做多工作簿合并是够用的，前提是每个来源文件里都只有一个工作表，这样顺序就能按列表顺序对上。
3.2 分类型导出各自控件的内存流
有了合并方法，前面缺失的一环就是“每个控件单独导出成流”。这里需要根据控件类型走不同的 API，但返回统一为 MemoryStream，方便合并方法接收。
GridView 的导出有两个注意点。第一个是如果用 ExportToXlsx 的默认重载，列宽会丢，导出来列变得又窄又挤；第二个是如果不关掉分组状态，导出的 Excel 里会出现分组的折叠行，报表的人可能不太想要的干净表。我一般会先给 view 做一次快照，导出完再恢复。
public static MemoryStream ExportGridViewToStream(GridView view) { var stream = new MemoryStream(); var options = new XlsxExportOptionsEx { ExportType = ExportType.WYSIWYG, SheetName = "主表" }; view.ExportToXlsx(stream, options); stream.Position = 0; return stream; }ExportType 设成 WYSIWYG 能最大程度保留界面上的样式布局，如果设成 Default，导出结果会比界面生硬不少。这个参数值的差异在合并后特别明显，WYSIWYG 出来的列宽和行高基本不用再手工调。
ChartControl 的导出更直接，图片型内容导出后是工作表中的嵌入图，不是单元格数据。ChartControl.ExportToXlsx 会保留图表为 Excel 图表对象，这在数据汇报场景里很占优势，对方拿到 xlsx 还能继续编辑数据系列。
TreeList 导出后是层级数据，DevExpress 的导出逻辑会把父子关系转成缩进的普通行，不是 Excel 里的分组行。这个行为有好有坏，好处是数据完整，坏处是某些业务期望点的加号展开效果，在 Excel 里不存在。常见做法是接受缩进式导出，或者在导出前把 TreeList 的数据平铺到 DataTable 再导出。
3.3 把外部参数组织成导出配置项
封装类做到这个程度，导出细节基本是稳定不变的，变的参数可以抽象成配置对象。每个控件配一个导出项，包含控件实例、工作表名称、导出类型和可选的过滤条件。
public class ExportItem { public Control Control { get; set; } public string SheetName { get; set; } public ExportType ExportType { get; set; } = ExportType.WYSIWYG; }配置的好处是界面代码不用关心每个控件的 API 细节，只是把待导出的控件装进 List ，调用统一方法完成全部导出。后续要增加新控件类型，只需要加一个类型分支，而不是在界面上再写一个 if。
4. 数据整理在前，控件导出在后：一份能被信任的 Excel 是怎样炼成的
4.1 GridView 导出前先做视图快照和筛选
很多开发者直接把 GridView 当前状态导出，结果用户看到的表和导出来的表不一致。原因是 GridView 的筛选、排序、列隐藏都会如实带进导出结果，用户以为导出的是全量数据，实际只是屏幕过滤后的子集。
常见的做法是导出前先存一下当前视图状态，然后按业务要求重置筛选和排序，导出后再恢复。这在报表场景里尤其重要，比如导“本月流水”时，界面上可能临时筛选了某个渠道，导出前不做重置，对方拿到手的表就缺数据。
public static MemoryStream ExportGridViewWithReset(GridView view, Func<GridView, MemoryStream> exportAction) { var state = view.SaveViewState(); view.ClearColumnsFilter(); view.ClearSorting(); var result = exportAction(view); view.RestoreViewState(state); return result; }SaveViewState 和 RestoreViewState 是 DevExpress 提供的配对 API，用来保存和还原整个视图设置。ClearColumnsFilter 会清掉列筛选，ClearSorting 会清掉排序，这两个调用之后导出的是无过滤的完整数据集。
要注意的是 RestoreViewState 必须在导出完成之后马上调用，最好放在 finally 里，否则中途抛异常，界面视图就停留在全量状态，用户会以为筛选失效了。我见过因为没做 finally 恢复，用户重新打开窗体才发现筛选被清了，这类小问题排查起来很费时间。
4.2 动态列导出要控制列顺序和列宽
实际项目里经常遇到动态列的情况，就是 DataTable 的列不是固定的，可能在运行时才确定。GridView 的列集合需要先同步到 DataTable 的结构，否则导出时列头对不上。
碰到这种情况，我一般会先把数据源 DataTable 的列顺序排好，然后重新设置 GridView 的列集合，再执行导出。列宽方面，常用做法是读取每个列的显示宽度，乘以经验系数后写入导出配置。DevExpress 的 Excel 导出默认列宽可能不够，长字段会被截断，所以手动调整是可预期的需求。
private static void ResizeColumnsForExport(GridView view, double factor = 1.2) { view.BeginUpdate(); for (int i = 0; i < view.Columns.Count; i++) { var col = view.Columns[i]; int contentWidth = col.GetBestWidth(); col.Width = (int)(contentWidth * factor); } view.EndUpdate(); }GetBestWidth 是 DevExpress 计算列最优宽度的方法，乘个系数留出余量，不要让文字紧贴边框。这个调整会影响界面显示，所以通常只做临时调整，导出完恢复旧值。更稳妥的做法是直接用 XlsxExportOptionsEx 的属性控制列宽策略。
4.3 合并多个控件时保持 Sheet 名称规律
多工作簿导出最直观的问题是 Sheet 名称。DevExpress 默认会生成 Sheet1、Sheet2 这种名字，用户拿到文件得一个一个去试。实用的做法是根据 ExportItem 里的配置名做重命名，这样打开文件第一眼就知道哪个表是哪个控件。
重命名时要避开 Excel 的命名规则坑，Sheet 名不能包含这些字符：冒号、反斜杠、问号、星号、方括号。如果配置名里带了这些字符，导出会异常。常见做法是配置名传入前先做一次清洗。
public static string SafeSheetName(string name, int maxLength = 31) { if (string.IsNullOrWhiteSpace(name)) return "Sheet"; foreach (var c in new[] { ':', '\\', '/', '?', '*', '[', ']' }) { name = name.Replace(c, '_'); } return name.Length > maxLength ? name.Substring(0, maxLength) : name; }MaxLength 是 Excel 的硬限制，31 个字符，超过了保存就会报错。清洗函数把非法字符替换成下划线，长度截断。这个函数放在公共类里，所有未配置 SheetName 的导出项都走一遍，能避免大量低级报错。
5. 避坑指南：导出流程里最容易翻车的七个细节
5.1 多个控件写入同一个文件流导致工作表互相覆盖
现象：循环导出多控件，最后打开文件只有一个工作表，且内容是最前面或最后面的控件数据。
原因：每个控件的 ExportToXlsx 都向同一个 FileStream 写内容，文件流被完整覆写，DevExpress 没有自动追加工作表的逻辑。
解决：每个控件先独立导出到 MemoryStream，再通过 SpreadsheetControl 合并工作表，最后保存到目标文件路径。核心思路是“先各自生成，后合并组装”。
5.2 ExportType 设置为 Default 导致样式丢失
现象：导出的 Excel 能打开，数据也对，但列宽挤成一团，表头背景色没有了，合并且单元格全部散开。
原因：ExportType.Default 走的是最保守的导出路径，它只保证单元格值完整，不保证界面样式还原。
解决：使用 ExportType.WYSIWYG，这个模式会按界面呈现效果写入样式。对报表类需求来说，WYSIWYG 是默认选项。
5.3 ViewState 没有恢复，界面筛选被清空
现象：执行导出后回到界面，之前的筛选条件全没了，数据变回全量。
原因：导出前调了 ClearColumnsFilter，但导出完成后没有执行 RestoreViewState，视图状态没有被还原。
解决：把视图快照和恢复放在 try-finally 里，确保任何路径下都会执行 RestoreViewState。这个点很隐蔽，尤其是导出过程中异常时，finally 是唯一能兜住恢复逻辑的地方。
5.4 导出大表时内存流没有释放，内存涨到几百 MB
现象：连续导出十几次后，程序内存占用明显上升，最终卡顿或崩溃。
原因：MemoryStream 和 SpreadsheetControl 的 Document 对象没有及时释放，托管的非托管资源都堆在内存里。
解决：每个 MemoryStream 用完进入 Dispose，SpreadsheetControl 用 using 包围。合并时临时打开的 sourceDoc 也要用完即关。导出量大的程序最好加一个日志点，看每个步骤的内存占用，直观了解泄漏点。
5.5 表格里含图片导致导出异常
现象：GridView 某一列是图片列，导出时报错或导出后图片无法显示。
原因：图片列的数据类型在导出时不能被 Excel 原生格式完整映射，DevExpress 对图片的支持依赖具体存储方式。
解决：常见做法是图片列单独处理，导出前把图片列的可见性关掉，另外把图片路径列导出文本，然后在 Excel 里做后续处理。除非业务确实需要图片嵌入，否则不要期望 DevExpress 自动把图片正确带进 xlsx。
5.6 控件在后台线程操作导致跨线程异常
现象：导出放在后台线程执行，执行到 GridView 导出时报 InvalidOperationException。
原因：DevExpress 的控件导出方法内部间接访问 UI 信息，比如列宽、可视状态，这些属性在非 UI 线程访问不被允许。
解决：后台线程不要碰控件实例，应当先在 UI 线程把 GridView 的视图数据快照到 DataTable，后台线导出的只是 DataTable 内容。这是个没得商量的限制，不要试图绕开跨线程检查。
5.7 Sheet 名称含非法字符导致保存失败
现象：合并时单独看没问题，最后 SaveDocument 时报异常，文件没生成。
原因：配置的 SheetName 里含有 Excel 禁止的字符，保存阶段 Excel 格式校验失败。
解决：所有配置名统一清洗一遍再用。我把 SafeSheetName 放在合并方法入口处，不管调用方传什么名都先进过滤器，从源头掐断问题。
6. 让导出更像成品：加一个可复用的样式与列宽整理技巧
导出功能能跑通只是第一步，交付的时候对方还是会挑“列宽不对”“表头不好看”这类细节。Autofit 列宽这块，DevExpress 提供了自动调整方法，但在合并多工作簿后，自动调列宽并不总是生效，需要手动补一步。
我现在的做法是封装一个 PostProcess 方法，在合并完成后重新计算每个工作表的数据列宽度。这个方法读取每一列的最大字符长度，换算成 Excel 列宽单位，再写回工作表。Excel 的列宽单位和像素不是一回事，需要按下述近似关系转换。
public static void AutoFitSheetColumns(Worksheet sheet, double padding = 2) { var used = sheet.GetUsedRange(); for (int col = 0; col < used.ColumnCount; col++) { int maxLen = 0; for (int row = 0; row < used.RowCount && row < 200; row++) { var cell = used[row, col]; if (cell.Value.IsText) { maxLen = Math.Max(maxLen, cell.Value.TextValue.Length); } } if (maxLen > 0) { double width = Math.Min(maxLen + padding, 60); used[0, col].Worksheet.Columns[col].Width = width; } } }这里的限制是只扫描前 200 行，数据量特别大的表省时间。实际业务中一般列头就是最长内容，就算有数据超过列头，200 行也足够覆盖绝大多数场景。Max(60) 是对超长文本的限制，避免出现一列拉满整个屏幕的情况，超长内容靠单元格换行来展示，而不是无限拉宽列。
调用位置在合并工作簿之后、SaveDocument 之前，这样每个工作表的列宽都统一整理过。宽度计算用文本长度加 padding 的方式，没有精确测量字距，但对大多数中文报表场景够了。做精确字体测量耗性能且收益有限，我不做。
真正复杂一点的场景是合并单元格区域的列宽调整。DevExpress 复制过来合并单元格并不是重新计算的列宽，原来界面上列宽合理，在 Excel 里可能就窄了。所以 AutoFit 要处理合并单元格所在区域，把它当成一整块内容来算宽度，再把宽度分配给区域内所有列。这个逻辑再往深走就属于特定报表定制了，一般内部工具到 AutoFit 这一步就够用了。
还有个容易被忽略的细节，是把重复表头行固定住。多工作簿导出，每个表最好在首行写明生成时间和数据来源，这样对方转发出去时别人能看懂。这个不用改导出逻辑，在合并前往 Worksheet 的首行插入几个单元格写信息即可，成本极低。
从那以后，我每次交付导出功能都会强制走一遍这套流程：先跑单控件内存流导出，再合并检查样式完整度，最后跑一遍 AutoFit 和 Sheet 名清洗。这套流程在模拟项目X、某跨平台系统里已经重复用过很多次，跑通以后导出这块基本没再返工过。希望帮到你。
本文还有配套的精品资源，点击获取
