做C#开发的朋友尤其是写过上位机、winform管理系统的肯定绕不开DataGridView这个控件。它够用、顺手但默认显示出来的数据往往很“原始”——数据库里存的0和1、枚举数值、时间戳、原始状态码直接怼到界面上用户看着就是一堆不明所以的符号。我最早做设备上位机的时候就被这玩意儿坑过当时测温度传感器数据源里存的是“0”“1”代表通断直接显示出来客户看了半天问我这一堆数字啥意思。后来琢磨明白格式化这块界面的可读性完全不一样了。这篇东西我不打算写成一本文档我把这几年用C#做DataGridView单元格格式化的实践经验整理一下从机制原理到实操代码再到踩坑记录一次性说透。如果你是刚接触winform或者正在做上位机界面优化这篇应该能帮你少走不少弯路。1. 先搞清楚DataGridView格式化到底在解决什么问题1.1 真实业务里单元格格式化的三种典型需求DataGridView单元格格式化说白了就是一件事数据源里存什么和界面上显示什么可以不一样。这个“不一样”在业务里有非常实际的场景。第一种是数据翻译。数据库或者硬件采集回来的数据往往是编码后的数值比如设备状态字段存的是0、1、2分别代表待机、运行、故障布尔字段存的是true/false或者干脆是0/1。你直接把0、1、2抛给用户没人看得懂。格式化的任务就是把“0”翻译成“待机”把“1”翻译成“运行”把true翻译成“是”假翻译成“否”。第二种是格式美化。日期时间存的是2024-05-01 08:30:00.000但界面上用户只关心2024-05-01或者只需要08:30这种时分格式浮点数存的是3.1415926界面上只需要两位小数大数值需要千分位分隔符。这些属于把原始数据转成更适合阅读的格式。第三种是条件样式。根据单元格的数值改变它的背景色、前景色、字体让异常数据一眼就能被看到。比如电压超过阈值就标红任务完成就标绿这种格式化和视觉化的结合是上位机和桌面管理软件最常见的信息展示需求。这三种需求前两种用DataGridView自带的一些简单的列类型和属性可以完成一部分但真正灵活、覆盖所有场景的方案是借助CellFormatting事件在单元格显示前做“最后一公里”的处理。1.2 格式化机制的核心认知显示值不等于数据源值很多人第一次接触格式化会有一个误区以为改单元格的Value就行了。我在代码里见过不少这样写的dataGridView1.Rows[i].Cells[3].Value 运行中;这种写法有一个严重问题你直接改掉的是数据源的值不是显示的值。一旦数据刷新、重新绑定这些新值会覆盖原有的真实数据你原本要保留的“0”和“1”就被破坏了后面想做任何聚合、导出、比对都会出错。正确的处理方式是理解DataGridView内部有两套值体系数据源值Value数据绑定后Cell.Value里面存的是原始数据这个值应该保持原样。显示值FormattedValue控件用于绘制显示的内容Cell.FormattedValue这个才是用户屏幕上看到的东西。CellFormatting事件就是在控件需要把一个单元格显示出来的时候触发的一个“转换点”。你在这个事件里操作的是“显示值”的生成过程数据源值一直保持稳定。这就是整个格式化的核心机制——展示层和数据层的解耦。打个日常生活的比方这就好比同一个人在银行系统里的身份信息是身份证号原始数据而在门禁系统的屏幕上显示的是工牌照片格式化后的显示值。你不能为了显示照片把身份证号抹掉它们本来就是两套东西。2. CellFormatting事件最核心的格式化入口2.1 事件触发机制与工作流程CellFormatting是DataGridView控件提供的一个事件当单元格需要被绘制时触发。它的触发时机有几个初次绑定数据、刷新界面、滚动表格、调用Refresh()或Invalidate()时凡是单元格从不可见变成可见或者内容被标记为需要重绘这个事件就会对相应的单元格触发。事件签名如下private void dataGridView1_CellFormatting(object sender, DataGridViewCellFormattingEventArgs e) { // e.RowIndex当前单元格所在行 // e.ColumnIndex当前单元格所在列 // e.Value单元格原始数据源值可读 // e.FormattedValue单元格格式化后的显示值可赋值 // e.CellStyle当前单元格的样式对象可修改 }基本流程是这样的控件需要绘制某个单元格。触发CellFormatting事件传入当前行列索引、原始值、默认样式。你在事件中根据业务规则判断如果这列需要格式化就计算出显示文本赋给e.Value或e.FormattedValue同时把e.FormattingApplied设为true。控件用你处理后的值绘制界面。这个流程每次重绘都会执行所以事件内部不要做耗时操作这一点后面讲性能的时候会专门提。2.2 给e.Value赋值还是给e.FormattedValue赋值这是新手特别容易迷糊的地方。在CellFormatting里有两个地方可以塞显示内容e.Value和e.FormattedValue。先说e.Value。在事件参数里e.Value代表这个单元格当前的值。如果你在CellFormatting里把e.Value改掉控件会直接用这个值作为显示值。在早期版本的.NET里很多人就是这么干的。但问题是e.Value的操作会影响后续的CellValueChanged事件判定也容易和数据源的真实值产生混淆。虽然在实际表现上多数情况能出效果但在语义上是模糊的。再说e.FormattedValue。这是专门为格式化后的显示值准备的属性。标准做法是private void dataGridView1_CellFormatting(object sender, DataGridViewCellFormattingEventArgs e) { if (dataGridView1.Columns[e.ColumnIndex].Name Status e.Value ! null) { int status Convert.ToInt32(e.Value); switch (status) { case 0: e.FormattedValue 待机; break; case 1: e.FormattedValue 运行中; break; case 2: e.FormattedValue 故障; break; } e.FormattingApplied true; } }关键点在于最后那个e.FormattingApplied true。这个标记告诉控件“我已经处理完格式化了你直接用FormattedValue显示就行不要再走默认格式化流程比如ToString、IFormattable那套”。如果你设置了FormattedValue但没有把FormattingApplied设为true控件的默认逻辑可能还会用原有Value再格式化一次导致你的改动被覆盖或者出现奇怪的表现。FormattingApplied这个坑我印象特别深有段时间我格式化日期在事件里按yyyy-MM-dd处理完了界面上显示的却是原始时间格式排查了半天才发现是没设这个标志位。设置之后一切正常。2.3 条件格式化按业务状态改单元格颜色和字体CellFormatting不只是改文本它还能拿到e.CellStyle直接对样式动手。这就是条件格式化的基础。举个设备运行状态监控的例子。界面里有一个“温度”列摄氏温度低于-10显示蓝色在-10到40之间显示正常黑字超过40显示红色加粗。代码如下private void dataGridView1_CellFormatting(object sender, DataGridViewCellFormattingEventArgs e) { if (dataGridView1.Columns[e.ColumnIndex].Name ! Temperature) return; if (e.Value null) return; double temp Convert.ToDouble(e.Value); if (temp 40) { e.CellStyle.ForeColor Color.Red; e.CellStyle.Font new Font(dataGridView1.Font, FontStyle.Bold); } else if (temp -10) { e.CellStyle.ForeColor Color.Blue; } e.FormattingApplied true; }这里e.CellStyle直接修改的是这个单元格的样式对象改动只影响当前这一个格子不影响整列其他格子。如果你要整列都变色更好的做法是在ColumnDefaultCellStyle或DataGridViewCellStyle里统一设置后面进阶部分会讲到。条件格式化还有一个常用方向根据某一列的值去控制整行显示。比如订单列表中“是否有异常”这一列如果是“是”整行背景变为浅红色。做法是在CellFormatting里判断这行的某个列值再修改同行的所有列的样式。因为CellFormatting是逐单元格触发的只改当前单元格的e.CellStyle没法实现整行变色你需要自己遍历行里的其他单元格。更优雅的做法是使用RowPrePaint事件或者CellFormatting配合e.RowIndex去操作Rows[e.RowIndex]下的每个Cell这块后面用一节专门展开。3. 典型场景实操把业务数据“翻译”成人能看懂的界面3.1 场景一把0和1显示为复选框DataGridView自带DataGridViewCheckBoxColumn列类型如果你直接给一列绑定布尔值的数据源控件会自动显示为复选框。但现实世界的数据源往往不那么听话很多数据库里存的是int类型的0和1或者string类型的“0”“1”。这种数据直接用DataGridViewCheckBoxColumn绑定很容易出现不显示勾选框、或者显示一个空框的问题。处理办法有两个。办法一在查询SQL或实体层就把0和1转成布尔值这是一个推荐的方案。你在获取数据时就将它们转换好控件层面完全不用操心。办法二使用普通DataGridViewTextBoxColumn列结合CellFormatting把0、1显示为勾选符号。我自己的经验是直接用Text列在格式化成字符串时没法做到真正的复选框交互用户不能点击切换。所以如果业务上需要用户点击修改这个值单纯格式化文本是做不到的。真正的复选框显示需要你理解一个机制DataGridViewCheckBoxColumn在把数据源值转换为显示状态时依赖的是值的类型。如果绑定的数据源值是int的0和1处理逻辑如下// 绑定数据源后在DataBindingComplete事件中处理 private void dataGridView1_DataBindingComplete(object sender, DataGridViewBindingCompleteEventArgs e) { foreach (DataGridViewRow row in dataGridView1.Rows) { DataGridViewCheckBoxCell cell row.Cells[IsEnable] as DataGridViewCheckBoxCell; if (cell ! null cell.Value ! null) { // 把0/1转换成bool cell.Value Convert.ToInt32(cell.Value) 1; } } }这种方式做完之后界面上会显示真正的复选框状态用户可以点击切换切换后Cell.Value会变成布尔值。如果你要写回数据库在保存的时候再做一次反向转换即可。还有另外一种思路如果你不想转换值也可以用CellFormatting把0/1映射成“√”和“×”这样的文本符号这在只读展示的场景下非常轻量。不同方案的选择标准只有一个用户需不需要直接在界面上点击改这个值。需要就用CheckBox列配合DataBindingComplete转换不需要用Text列加CellFormatting也完全够用。3.2 场景二日期时间的美化显示日期时间的格式化很多人以为设置列的DefaultCellStyle.Format就够了比如yyyy-MM-dd HH:mm:ss。确实这个方式对常规日期格式非常有效但它有两个局限第一格式字符串不支持条件判断。比如你想在当天显示“今天 08:30”昨天显示“昨天 18:20”更早的显示完整日期Format属性就无能为力了。第二如果数据源里的日期不是DateTime类型而是字符串或者其他类型Format属性不一定生效。尤其是从某些设备接口拿到的数据可能是Unix时间戳可能在字符串里还带着时区信息。所以遇到稍微复杂一点的日期显示需求就得在CellFormatting里自己处理。以下是我常用的一段代码把时间戳和常规日期都兼容处理private void dataGridView1_CellFormatting(object sender, DataGridViewCellFormattingEventArgs e) { if (dataGridView1.Columns[e.ColumnIndex].Name ! CreateTime) return; if (e.Value null) return; DateTime time; if (e.Value is DateTime dt) { time dt; } else if (long.TryParse(e.Value.ToString(), out long timestamp)) { // 兼容Unix时间戳秒级 time DateTimeOffset.FromUnixTimeSeconds(timestamp).ToLocalTime().DateTime; } else { return; } if (time.Date DateTime.Today) { e.FormattedValue 今天 time.ToString(HH:mm); } else if (time.Date DateTime.Today.AddDays(-1)) { e.FormattedValue 昨天 time.ToString(HH:mm); } else if (time.Year DateTime.Today.Year) { e.FormattedValue time.ToString(MM-dd HH:mm); } else { e.FormattedValue time.ToString(yyyy-MM-dd HH:mm); } e.FormattingApplied true; }这样处理后界面上显示的时间话术语义更强操作人员一眼就能分辨最近的消息是什么时候产生的。这段代码在设备告警、消息列表这种场景里非常实用。3.3 场景三数字与计量单位格式化数字格式化是一个经常被低估的环节。温度显示20.0000001℃和显示20.00℃对操作人员的观感差别很大。设备电压可能显示219.583724V但你实际需要的是219.6V。如果你用常规的DefaultCellStyle.Format属性可以这样dataGridView1.Columns[Voltage].DefaultCellStyle.Format F2;F2代表固定两位小数。其他常用格式还有N0千分位不带小数、N2千分位带两位小数、P百分比、E科学计数法。这些内置格式覆盖了大部分常规数字显示需求。但单位就麻烦了。你不可能通过Format属性在数字后面自动加“℃”“V”“MPa”这些单位。有人用字符串拼接在数据源里就拼好比如Voltage.ToString(F2) V这又犯了直接改数据源值的毛病。正确的做法还是在格式化事件里处理private void dataGridView1_CellFormatting(object sender, DataGridViewCellFormattingEventArgs e) { if (dataGridView1.Columns[e.ColumnIndex].Name Voltage e.Value ! null) { double voltage Convert.ToDouble(e.Value); e.FormattedValue voltage.ToString(F2) V; e.FormattingApplied true; } }这样处理显示友好数据源里的电压数值仍然保留着完整精度导出Excel、做趋势曲线图的时候用的还是原始数据不会因为显示的时候舍入两位小数而丢精度。这个“显示归显示、数据归数据”的原则同样适用于百分比、汇率、大数字单位转换等场景。我做过一个能耗监控界面电表的读数最大可以到几万度电数据源里是精确到小数点后四位的浮点。界面上直接显示几千度带上四位小数看着很费劲。后来我改成数值小于100显示两位小数大于1000自动换算成“1.234万度”的格式。这种人性化的显示方案用户反馈特别正面。4. 进阶技巧格式化之外的常见需求一并解决4.1 用DataGridViewCellStyle做整行或整列统一样式前面用的e.CellStyle是修改单个单元格的样式。但实际开发中经常会有“整列的所有单元格都左对齐”“整行背景统一着色”这种批量需求。这就要用到DataGridViewCellStyle。整列样式可以在设计器里设置也可以在代码里初始化DataGridViewCellStyle style new DataGridViewCellStyle(); style.Alignment DataGridViewContentAlignment.MiddleRight; // 右对齐适合数字列 style.Format N2; // 默认数字格式 style.ForeColor Color.FromArgb(64, 64, 64); style.Font new Font(Microsoft YaHei, 9F); dataGridView1.Columns[Price].DefaultCellStyle style;整行样式通常放在DataBindingComplete或RowsAdded里设置但如果你需要根据单元格数据动态决定整行样式可以用RowPrePaint事件private void dataGridView1_RowPrePaint(object sender, DataGridViewRowPrePaintEventArgs e) { DataGridViewRow row dataGridView1.Rows[e.RowIndex]; object statusValue row.Cells[Status].Value; if (statusValue null) return; int status Convert.ToInt32(statusValue); Color rowColor status switch { 0 Color.LightGray, // 待机 1 Color.LightGreen, // 运行 2 Color.LightCoral, // 故障 _ Color.White }; for (int i 0; i row.Cells.Count; i) { row.Cells[i].Style.BackColor rowColor; } }RowPrePaint的触发时机在行绘制之前适合做整行级样式设置。要注意的是这里遍历行内所有单元格去设置Style.BackColor性能上会有一些开销如果行数特别大几千行以上更高效的做法是配合CellFormatting只处理当前单元格同时判断一下这行状态。关于性能优化下一节专门展开。4.2 格式化优先级事件处理与默认样式谁说了算一个单元格的最终显示可能同时受到默认样式、列样式、单元格样式、CellFormatting事件等多层影响。这里有一个优先级排序记住它很多问题能迎刃而解优先级从高到低单元格自身样式Cell.StyleCellFormatting事件中对CellStyle的修改列默认样式Column.DefaultCellStyleDataGridView控件默认样式系统默认样式具体到文本格式化的优先级CellFormatting事件中设置FormattingApplied true并赋值FormattedValueCellFormatting事件中修改了e.ValueCellStyle.Format格式字符串默认ToString()从实际排错的角度这个优先级的意义在于当界面显示和你预期不符时你要按这个顺序去排查是哪一个环节覆盖了你的设置。我见过一个案例同事在CellFormatting里根据业务逻辑设置e.FormattedValue 超时但界面上还是显示原始数字。后来发现FormattedValue是设置了但漏了FormattingApplied true控件的默认格式化流程把FormattedValue又覆盖回去了。这个案例非常典型值得新手朋友注意。4.3 性能优化别让格式化成为界面卡顿的元凶CellFormatting是逐格触发的一个1000行、10列的表格一次刷新就会触发1万次事件。如果事件里写了耗时的操作比如访问数据库、解析文件、正则匹配复杂文本、频繁new Font界面卡顿是必然的。性能优化的原则第一事件处理里不要做IO操作。需要查字典、查配置的提前在前端用Dictionary或数组构建好映射关系。我一般把枚举翻译表放在一个静态字典里private static readonly Dictionaryint, string StatusMap new() { {0, 待机}, {1, 运行}, {2, 故障} };然后在事件里直接查表比每次switch还要快代码也更整洁。第二不要在事件里创建字体或画刷。new Font()是一个相对昂贵的操作。如果确实需要加粗热区单元格把字体对象缓存成静态字段避免每次触发都new一个出来。第三使用e.CellStyle修改样式时尽量复用已有对象不要每次new一个DataGridViewCellStyle。CellStyle的修改本身就有内部缓存机制你直接改属性比替换整个对象开销小。第四能用DataGridViewCellStyle.Format解决的场景不要走CellFormatting事件。比如标准的日期格式、固定小数位数、千分位格式直接设置在列样式上控件内部处理效率最高。事件处理留给那些确实需要逻辑判断的场景。第五大表格批量更新时先挂起布局。如果一次要刷新很多行的内容先把dataGridView1.SuspendLayout()处理完后再ResumeLayout()这能大幅减少重绘次数。绑定数据源时把整个数据源列表构建完一次性绑定不要一行一行往Rows集合里Add。性能问题不是等你卡了才去优化而是在设计格式化方案时就要问自己这个格式化的频率有多高每个格子处理的开销有多大有没有更高效的内置方案4.4 与DataGridView其他事件的配合逻辑CellFormatting不是孤立的它和几个兄弟事件配合使用才能完成完整的显示逻辑。CellValueChanged当单元格的值被修改后触发通常用于数据校验、实时保存、联动其他列。这个事件里拿到的是修改后的Value不是格式化后的FormattedValue。如果你在这个事件里也做显示转换逻辑会重复而且可能互相覆盖。我的建议是显示转换集中在CellFormatting里做值变更处理放在CellValueChanged里做两个事件的关注点彻底分开。DataBindingComplete数据绑定完成后触发适合做一次性的列初始化和数据预处理。比如前面提到的把0/1转布尔值可以在DataBindingComplete里统一处理。这个时机比CellFormatting早适合做全局性的数值清洗。RowsAdded新行添加时触发适合为新行设置默认值。如果你在CellFormatting里根据别的列值做条件格式化新添加的行可能因为其他列还没有值导致格式化逻辑提前退出或异常。这种情况下在RowsAdded里先给新行的关键列设置默认值能避免很多边界问题。CellPainting最底层的绘制事件。当CellFormatting已经无法满足需求时比如你需要在单元格里绘制自定义图形、图标、进度条才考虑用CellPainting自定义绘制。这个事件完全接管了单元格的绘制复杂度高很多一般情况下用不到。事件配合的核心原则是各司其职不要堆在同一个事件里做所有事情。5. 常见问题排查手册5.1 格式化不生效或显示异常这是遇到最多的问题现象千奇百怪有的改了FormattedValue不显示有的显示了一两个字符就乱了有的滚动之后才恢复。排查顺序建议按这个来检查FormattingApplied是否设置为true。这是第一坑我前面反复提了。设置了FormattedValue但没设这个标志控件可能用原始值重新格式化一遍。请记住这个排查优先级第一因为发生的频率最高。检查事件绑定是否生效。在运行时用断点看CellFormatting到底进没进。有些情况下你在设计器里挂上了事件但代码里又动态生成了列导致事件里Columns[e.ColumnIndex].Name和实际名称对不上判断条件一直不满足格式化代码根本没执行。DataGridView自动生成的列名和列头文本可能不同你需要用DataPropertyName或Name仔细核对。检查e.Value是否为空。数据源中有些单元格是DBNull或者null在CellFormatting里如果直接Convert.ToInt32(e.Value)会抛异常导致整个事件中断。建议每次先判空if (e.Value null || e.Value DBNull.Value) return;检查是否有其他代码覆盖了显示值。比如你在CellFormatting里设置的是这个值但CellPainting或其他自定义绘制又把内容重新画了一遍。或者你在CellValueChanged里改了Value触发了链式反应。多用断点逐步排除。5.2 事件反复触发导致界面闪烁如果你发现界面滚动的时候不规则闪烁或者格式化逻辑执行次数远超预期大概率是事件内代码触发了重绘。一个常见的情况在CellFormatting里修改了e.CellStyle的某个属性而该属性的变化又导致DataGridView判定该单元格需要重新绘制于是再次触发CellFormatting形成递归。虽然控件有内部机制防止无限递归但会导致不必要的重复计算。另一个常见情况在CellFormatting里调用了dataGridView1.Refresh()或Invalidate()。这个操作会强制全表重绘然后触发所有单元格的CellFormatting事件事件里又调用Refresh()这里就会造成严重的性能问题和闪烁。我总是反复提醒自己事件里永远不要去主动Refresh。如果闪烁严重尝试以下优化手段设置dataGridView1.DoubleBuffered true;这个属性可以减少绘制闪烁。减少事件内的操作量能缓存的提前缓存。如果格式化逻辑复杂把判断条件尽量往前放不符合条件时快速返回减少不必要的逻辑执行。5.3 与数据源类型相关的隐藏问题数据源的列类型直接决定了e.Value的运行时类型。同一个“状态”字段在DataTable里可能是int在实体类里可能是enum在第三方接口里可能是string。Convert.ToInt32对大多数类型都能处理但有两个隐藏问题枚举类型的处理。如果你绑定的是实体集合且属性是枚举类型e.Value在CellFormatting里拿到的就是那个枚举对象。你可以直接判断if (e.Value is DeviceStatus status) { e.FormattedValue status switch { DeviceStatus.Ready 待机, DeviceStatus.Running 运行中, DeviceStatus.Fault 故障, _ status.ToString() }; }这里用switch表达式而不是直接的e.Value.ToString()是因为直接ToString()默认输出枚举名称界面上显示的是英文不符合中文界面的需求。字符串数字的陷阱。如果数据源里存的是字符串“1.50”你在格式化时Convert.ToDouble(e.Value)会成功但如果字符串是“1,50”某些区域设置的逗号小数点Convert.ToDouble可能因为当前线程的区域设置而抛出异常。处理这类数据建议使用CultureInfo.InvariantCulturedouble val Convert.ToDouble(e.Value, System.Globalization.CultureInfo.InvariantCulture);DataTable中DBNull和空字符串的区分。DataTable未赋值的单元格是DBNull.Value而绑定ListT实体类时未赋值的是null。在CellFormatting里统一处理时要兼容这两种情况。我见过有人只判了 null结果用DataTable绑定时抛异常。5.4 格式化后导出Excel或打印时样式丢失使用CellFormatting做的格式化只在界面上生效当你把数据导出到Excel、或者用PrintDocument打印时这些显示值不会自动带过去。这个问题在上位机报表导出场景非常常见。解决方案是要么在导出时重新执行一遍同样的格式化逻辑要么直接把Cell.FormattedValue导出。我给一个最简单的导出逻辑思路// 导出时对每一行每一列取FormattedValue for (int i 0; i dataGridView1.Rows.Count; i) { for (int j 0; j dataGridView1.Columns.Count; j) { object displayValue dataGridView1.Rows[i].Cells[j].FormattedValue; // 把displayValue写入Excel单元格 } }注意FormattedValue属性在获取时会触发一次格式化计算所以对于大数据量导出这个过程也会调用CellFormatting事件是比较耗时的。可以先SuspendLayout对性能有帮助但导出本身耗时无法完全避免。如果导出的是原始值而不是显示值那就直接读Value两者用途不同取决于业务需要。一般而言导出报表用户看到的是格式化后的中文、日期、单位导出原始值意义不大除非是做数据清洗备份。6. 我踩过的一些坑分享给你做DataGridView格式化这几年我踩过的坑比写出来的代码多。挑几个印象深刻的你如果也遇到类似的能省不少排查时间。第一个坑是在CellFormatting里弹对话框。有个需求说状态为“故障”时界面上弹窗提示操作员。我图省事直接在格式化事件里MessageBox.Show结果表格刷新一次连续弹了三四个框。原因很简单CellFormatting是逐格触发的状态列有几十行的单元格是故障状态每个格子触发一次就弹一次。后来改成在CellValueChanged里加上一次性的状态判断用标志位控制只弹一次彻底解决。第二个坑是格式化代码里用了当前行的其他单元格值。你在CellFormatting里访问dataGridView1.Rows[e.RowIndex].Cells[其他列].Value数据通常没问题但需要注意行列索引在CellFormatting触发时并不保证所有单元格的值都已经填充完成。尤其在DataBindingComplete之前部分单元格的值可能还是默认的。这会导致偶发的空引用异常。处理方式是在取值前先判空或者把判断逻辑放在DataBindingComplete之后触发一次全量刷新在刷新时各列的值已经齐了。第三个坑是CellFormatting和CellValueChanged之间互相触发。你有一次在CellFormatting里改了e.Value而CellValueChanged在值变化时会触发导致格式化逻辑又跑一遍再触发值变化——无限循环。处理办法是严格区分CellFormatting里只改FormattedValueCellValueChanged里只处理真正的数据变更千万不要串。第四个坑是列索引动态变化。如果你在代码里动态增删列用Columns[e.ColumnIndex].Name做查找是安全的但如果在运行时修改了列的Index比如重新排列事件里的索引可能对不上。所以我强烈建议始终用Column.Name而不是硬编码ColumnIndex。说回格式化这件事本身我的总体体会是DataGridView单元格格式化不难难点在于想清楚“显示”和“数据”的边界。界面上展示出来的永远是格式化之后的结果而数据源里保存的永远是原始值。把这两个概念刻在脑子里绝大多数格式化问题你都能迎刃而解。最后再分享一个小细节格式化的时候不要一次性把所有列的格式化逻辑全堆在CellFormatting里那样代码会越来越臃肿。我习惯把每种格式化逻辑独立成一个私有方法比如FormatStatusColumn、FormatDateTimeColumn在CellFormatting里根据列名去分发调用。这样代码结构清晰后面加需求只需要新增一个方法不用去改动事件的整体框架。这个方法在项目持续演进时能帮你省下大量维护时间。