C# WinForms DataGridView 合并单元格实战：原理、代码与避坑指南

简介：这份资源面向使用 C# 开发 Windows Forms 应用的开发者，聚焦 DataGridView 控件的单元格合并问题，适合已掌握控件基本操作、希望实现复杂表格布局的中级学习者。内容围绕逻辑合并与视觉合并两种思路展开，重点讲解通过重写 OnPaint 事件自定义绘制单元格、设置对齐方式与列宽模式、处理行头合并以及嵌入自定义控件等关键实现细节，可帮助读者理解控件事件处理与图形绘制的结合方式。资源包共 22 个文件，以 cs 源码、exe 可执行程序、resx 与 resources 资源文件为主，另含 sln 解决方案、csproj 项目文件及少量配置与说明文件，整体约 44KB，结构完整可直接运行调试。目前已有 349 人学习下载，适合作为实现合并单元格功能的参考范例与排错对照。

1. DataGridView 合并单元格：一个被低估的“视觉刚需”场景

做过 WinForms 桌面项目的人大概都遇到过这种需求：一张订单明细表，同一个订单号下面挂着五六行商品，客户盯着屏幕看了半天，问你“为什么订单号要重复写六遍”。这不是审美问题，是信息密度问题——重复的单元格把真正有差异的数据淹没了。DataGridView 原生并不提供“合并单元格”这个属性，它只有CellPainting事件和MergeCells这种半成品方案，前者要自己画，后者在数据绑定场景下经常翻车。所以这个资源包解决的就是一件事：在 C# WinForms 的 DataGridView 里，把相邻且值相同的单元格在视觉上合并成一个，同时保证选中、滚动、排序、编辑这些交互不崩。适合正在维护老桌面项目、又不想为了一个表格去换整个 UI 框架的从业者。下面按“原理怎么立住 → 代码怎么抄 → 坑在哪 → 怎么验证”的顺序拆。

2. 合并的底层逻辑：为什么不能直接改单元格结构

2.1 DataGridView 的绘制模型决定了“合并”只能是视觉层的事

很多人第一反应是“把两个单元格对象合成一个”，这个思路在 DataGridView 里走不通。它的行是DataGridViewRow，单元格是DataGridViewCell，每个单元格的位置由行索引和列索引唯一确定，内部维护的是一个二维网格结构。你没有办法让一个 cell 横跨两列还保持索引体系不变，强行改会直接破坏Rows[i].Cells[j]的寻址逻辑，后续的取值、排序、导出全乱。

所以业界通行的做法是在绘制层做文章：数据模型不动，仍然是一行一个完整记录，只是在CellPainting事件里判断“当前单元格和左边（或上边）的单元格值相同”，如果相同就把边框画掉、背景画成一体，只在合并区域的第一个单元格里画文字。这样视觉上是一个大格子，逻辑上还是多个小格子，取值、绑定、导出都不受影响。这个资源包的核心类就是围绕这个思路封装的，把判断逻辑和绘制逻辑收进一个可复用的辅助类里，调用方只需要挂一个事件。

理解这一点很关键，因为它决定了后面所有参数的含义：合并的“粒度”是按列配置的，合并的“触发条件”是值相等，合并的“边界”是连续相同值的区间。任何超出这个模型的期待，比如跨行跨列的二维合并、合并后还能编辑中间格，都需要额外处理，不是改一个属性就能解决的。

2.2 按列配置合并策略：哪些列该合、哪些列绝不能合

不是所有列都适合合并。订单号、客户名、日期这类“分组键”适合合并；金额、数量、商品名这类“明细值”合并了反而误导。资源包的做法是给每一列一个布尔标记，只有标记为 true 的列参与合并判断。常见配置如下：

配置方式一般是在窗体初始化时遍历列，按Name或Index打标记。这里有个容易忽略的点：合并判断依赖“相邻行值相等”，所以数据源必须先按分组键排序，否则相同的订单号散落在不同位置，合并逻辑会画出断裂的色块。资源包里没有替你做排序，这是调用方的责任，后面避坑章节会专门讲。

2.3 绘制流程拆解：从 CellPainting 到边框擦除

具体到代码，核心是重写CellPainting的处理链。标准流程分四步：第一步判断当前单元格是否属于某个合并区间；第二步如果是区间首格，正常画内容和背景；第三步如果是区间中间格或尾格，用背景色填充并跳过内容绘制；第四步统一擦除区间内部的横线边框，只保留区间首尾的外框。

// 合并绘制核心：在 CellPainting 中拦截并重绘 private void grid_CellPainting(object sender, DataGridViewCellPaintingEventArgs e) { if (e.RowIndex < 0 || e.ColumnIndex < 0) return; // 只处理配置为可合并的列 if (!_mergeColumns.Contains(e.ColumnIndex)) return; // 向上找连续相同值的起始行 int startRow = e.RowIndex; while (startRow > 0 && IsSameValue(startRow - 1, e.RowIndex, e.ColumnIndex)) startRow--; // 向下找连续相同值的结束行 int endRow = e.RowIndex; while (endRow < grid.Rows.Count - 1 && IsSameValue(endRow + 1, e.RowIndex, e.ColumnIndex)) endRow++; // 非区间首格：只填背景，不画内容 if (e.RowIndex != startRow) { e.Graphics.FillRectangle(new SolidBrush(grid.BackgroundColor), e.CellBounds); e.Handled = true; return; } // 区间首格：正常绘制，但高度扩展到整个区间 Rectangle mergeRect = e.CellBounds; for (int r = startRow + 1; r <= endRow; r++) mergeRect.Height += grid.Rows[r].Height; using (var brush = new SolidBrush(e.CellStyle.BackColor)) e.Graphics.FillRectangle(brush, mergeRect); // 画文字，垂直居中 TextRenderer.DrawText(e.Graphics, e.FormattedValue?.ToString(), e.CellStyle.Font, mergeRect, e.CellStyle.ForeColor, TextFormatFlags.VerticalCenter | TextFormatFlags.Left); // 只画外框，不画内部横线 ControlPaint.DrawBorder(e.Graphics, mergeRect, grid.GridColor, ButtonBorderStyle.Solid); e.Handled = true; }

IsSameValue是比较两个行在指定列上的显示值，注意要用FormattedValue而不是Value，否则日期、枚举这类做了格式化的列会判断失误。mergeRect的高度累加依赖每行的实际高度，如果行高不固定（比如开启了自动换行），累加逻辑要改成遍历Rows[r].Height实时求和，不能假设统一行高。e.Handled = true是必须的，否则默认绘制会在你画完之后再叠一层，出现重影。这段代码是资源包里MergeHelper类的简化版，实际封装还处理了选中态高亮和交替行色，思路一致。

3. 把合并接进现有项目：绑定、排序与选中态的三处改造

3.1 数据绑定后合并失效？先查排序和 FormattedValue

最常见的翻车场景是：代码写好了，事件也挂了，运行起来却一个格子都没合并。排查顺序应该是这样的。第一，确认数据源是否已按合并列排序，DataTable.DefaultView.Sort或 LINQ 的OrderBy都行，但必须在绑定之前完成，绑定后再排序会触发重绘但合并判断用的是旧顺序。第二，确认IsSameValue取的是FormattedValue，如果列做了DefaultCellStyle.Format，Value是原始对象，两个DateTime对象即使显示同一天也可能因为时分秒不同而不相等。第三，确认事件挂的是CellPainting而不是CellFormatting，后者改的是值不是绘制。

// 绑定前先排序，保证相同分组键连续 var view = dataTable.DefaultView; view.Sort = "OrderNo ASC, LineNo ASC"; grid.DataSource = view; // 比较时统一取格式化后的显示值 private bool IsSameValue(int rowA, int rowB, int col) { var a = grid.Rows[rowA].Cells[col].FormattedValue?.ToString() ?? ""; var b = grid.Rows[rowB].Cells[col].FormattedValue?.ToString() ?? ""; return string.Equals(a, b, StringComparison.Ordinal); }

排序字段的选择有讲究：如果只按订单号排，同一订单内的明细行顺序是数据库返回的原始顺序，通常没问题；但如果业务要求明细按行号展示，就得把行号作为第二排序键，否则合并区间内的行序可能和预期不符。StringComparison.Ordinal是刻意选的，避免文化相关的比较规则导致“01”和“1”被判等，这类细节在导出对账时会被放大。

3.2 选中态和滚动闪烁：双缓冲与 Invalidate 的配合

合并绘制挂上去之后，第二个高频问题是滚动时闪烁，以及选中某一行时合并区域的高亮只亮一格。闪烁的根因是CellPainting里频繁创建SolidBrush和Pen，加上 DataGridView 默认没开双缓冲。解决办法两条：一是把画刷提成字段复用，二是给 DataGridView 开双缓冲。

// 开启双缓冲，消除滚动闪烁 typeof(DataGridView).InvokeMember("DoubleBuffered", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetProperty, null, grid, new object[] { true }); // 选中态：整段合并区域统一高亮 if (grid.Rows[e.RowIndex].Selected) { using (var selBrush = new SolidBrush(grid.DefaultCellStyle.SelectionBackColor)) e.Graphics.FillRectangle(selBrush, mergeRect); }

双缓冲通过反射设置DoubleBuffered属性是 WinForms 里的老手法，因为该属性在 DataGridView 上是 protected 的。选中态的处理要注意顺序：先填选中色再画文字，否则文字会被盖住。另外，如果开启了MultiSelect，用户框选多行时合并区域的高亮判断要以“区间内任一行被选中”为准，不能只看首行，否则会出现半截高亮的割裂感。资源包里对这块做了封装，调用方只需要在CellPainting开头调一个ApplySelectionStyle方法。

3.3 导出与打印：合并是视觉层，导出必须自己补

这是最容易被忽略的一环。因为合并只发生在绘制层，DataGridView的数据模型里每一行仍然是完整的，所以直接foreach导出的 Excel 或 CSV 会是“每行都带订单号”的原始形态，和屏幕上看到的不一致。如果业务方要求导出结果和界面一致，就得在导出逻辑里单独做一次合并：按分组键遍历，相同值的单元格留空或做纵向合并。

// 导出时按分组键做纵向合并（以 NPOI 为例） int startRow = 1; for (int i = 1; i <= data.Rows.Count; i++) { bool boundary = i == data.Rows.Count || data.Rows[i]["OrderNo"].ToString() != data.Rows[startRow - 1]["OrderNo"].ToString(); if (boundary && i - startRow > 1) { // 合并 startRow 到 i-1 行的订单号列 sheet.AddMergedRegion(new CellRangeAddress(startRow, i - 1, 0, 0)); } if (boundary) startRow = i + 1; }

这段逻辑的关键是边界判断：i走到分组键变化的位置或数据末尾时，如果区间长度大于 1 才合并，单行不合并。CellRangeAddress的行列索引是 0 基，表头占第 0 行，所以数据从第 1 行开始。打印同理，DataGridView自带的Print方法走的是同一套绘制，合并会生效，但如果用DrawToBitmap截图再打印，要确认截图时控件已完成布局，否则合并区域可能只画了一半。

4. 避坑清单：五条血泪经验

4.1 合并后点击中间格取不到值

现象：用户点了合并区域的第二行，CurrentCell落在第二行，但界面上看起来点的是那个大格子，业务代码取CurrentCell.Value拿到的是第二行的值，和视觉预期不符。原因：合并只是绘制层，命中测试仍然按原始网格走。解决：在CellClick或SelectionChanged里把CurrentCell重定向到区间首格，或者业务层统一按“区间首格取值”的约定处理，别依赖用户点在哪。

4.2 排序后合并区域错位

现象：点列头排序，合并的色块跑到不相邻的行上去了。原因：DataGridView 的自动排序只重排显示顺序，CellPainting里的IsSameValue按新顺序比较，但相邻行可能本来不相邻，合并判断基于“当前显示顺序”本身没错，错在数据源排序和显示排序不一致时区间被打断。解决：禁用列头自动排序，改为在SortCompare或数据源层排序后重新绑定，保证合并判断和显示顺序同源。

4.3 行高不一致导致合并框高度算错

现象：开了自动换行的列，合并区域的外框比实际内容矮一截或高出一截。原因：代码里假设了统一行高，用e.CellBounds.Height * 行数算总高。解决：改成遍历区间内每一行累加grid.Rows[r].Height，并且监听RowHeightChanged事件触发Invalidate，否则用户手动拖行高后合并框不会跟着变。

4.4 编辑态下合并区域被拆开

现象：双击合并区域进入编辑，格子突然变回单个单元格大小，编辑框只覆盖一行。原因：进入编辑时 DataGridView 用EditingControl覆盖当前单元格，绘制事件被绕过。解决：对参与合并的列设置ReadOnly = true，合并列本来就是分组键，通常不需要就地编辑；如果确实要编辑，得在EditingControlShowing里手动调整编辑控件的高度和位置，成本较高，不建议。

4.5 大数据量下滚动卡顿

现象：几千行数据，滚动时明显掉帧。原因：每次CellPainting都向上向下线性扫描找区间边界，最坏情况 O(n²)。解决：在数据绑定完成后预计算每个单元格所属区间的起止行，存进字典或二维数组，绘制时 O(1) 查表；数据变更时只重算受影响的分组。资源包里提供了BuildMergeIndex方法做这件事，数据量超过两千行建议开启。

5. 验证合并是否真的生效：三个可复现的检查点

写完代码别急着交付，按下面三个检查点走一遍，基本能覆盖八成问题。第一个检查点是“视觉一致性”：把界面截图和导出文件并排看，合并区域的位置、文字对齐、边框是否一致，重点看区间首格文字是否垂直居中、区间内部有没有残留横线。第二个检查点是“交互正确性”：依次点击合并区域的首行、中间行、尾行，确认CurrentCell重定向逻辑生效，选中高亮覆盖整段，滚动到视口外再滚回来不闪烁。第三个检查点是“数据完整性”：合并前后分别导出一次，用 diff 比对数据行数和每行的值，确认合并没有吞掉任何一条明细——这是合并功能最危险的失败模式，视觉上好看但数据丢了。

// 自检：合并前后数据行数必须一致 int before = dataTable.Rows.Count; ApplyMerge(grid, new[] { 0, 1 }); // 合并第 0、1 列 int after = ((DataTable)grid.DataSource).Rows.Count; Debug.Assert(before == after, "合并不应改变数据行数");

这个断言看着简单，但我在一个对账项目里就是靠它拦住了一次事故：当时为了“优化”合并逻辑，误在CellFormatting里把重复行的值置空，界面看着对，导出少了一半金额。从那以后我每次改合并相关代码，都强制先跑一遍行数断言再跑导出 diff，两步都过才允许提交。合并单元格这件事，视觉是表象，数据不丢才是底线。希望帮到你。

本文还有配套的精品资源，点击获取