如果你长期写 VB.NET 代码尤其在数据访问这一块摸爬滚打大概率被两个“空”折磨过——一个叫 Nothing一个叫 DBNull。很多从 C# 转过来的朋友第一反应是“这不都是 null 嘛”实际上两者从设计目的到判断方式、从读写行为到踩坑姿势差别非常大。我早年带项目时就因为用 Not Is Nothing 去判断数据库字段是否为空结果分支死活进不去最后定位到问题才发现读出来的是一个叫 DBNull.Value 的家伙。这种坑网上零散资料不少但把两者系统讲透的文章不多。今天这篇就用实际场景把 Nothing 和 DBNull 的来龙去脉说清楚。读完你不仅知道它们是什么还能明白为什么 VB.NET 要搞出两个“空”以及读写数据库时怎么选才不翻车。适合刚上手 VB.NET 的开发者也适合团队里经常写数据层的老手拿来当培训参考。1. 为什么这两个概念总是被搞混1.1 一次让我印象深刻的线上故障我先说一个真实踩坑经历。那时候负责一个库存报表系统每天凌晨批量导入供应商数据。某天线上反馈某类商品的数量列总是显示为 0但数据库里明明有部分行是 NULL日常逻辑是“如果是空值就显示为 0”听上去没毛病对吧。业务代码写的是If dr(Quantity) Is Nothing Then quantity 0 Else quantity CInt(dr(Quantity)) End If但实际结果是数据库里的 NULL 被 ADO.NET 读出来后不是 Nothing而是 DBNull.Value。这个判断永远不成立于是系统直接去执行 CInt(dr(Quantity))CInt 遇到 DBNull.Value 时不会当成 0 来处理运行到一半就炸了。那一晚我盯着异常日志才第一次认真研究 DBNull 到底是个什么东西。从那以后我得出一个结论搞不清 Nothing 和 DBNull 的边线轻则显示错误重则拖垮整个批处理任务。这不是一个可以含糊的小语法点。1.2 一句话先记住核心差异用最直白的话概括Nothing 是“这个变量还没指向任何对象”属于 VB.NET 语言层面的概念DBNull.Value 是“数据库字段的值是 NULL”属于 ADO.NET 数据层面的概念。这两个概念之所以容易混淆是因为它们在“读数据库空值”时会同时出现。你从 DataReader 或 DataRow 里取字段如果该字段是 NULL拿到的对象就是 DBNull.Value而不是 Nothing。如果你自己声明一个字符串变量但没赋值它的默认值才是 Nothing。打个比方Nothing 是一个空信封上面什么都没写DBNull 是一张写了“空”字的纸条。两者看起来都表示“没有内容”但来源和含义完全不同。1.3 本文覆盖的内容范围后续章节我会按这个顺序展开先拆解 Nothing 和 DBNull 各自的设计来源再对比它们的判断方式与底层差异然后重点讲数据访问实战里的读取、写入和参数传递问题最后给你一份常见误区速查表和一套可落地的编码约定。这里面既有理论讲解也有可以直接抄走的辅助函数目标是让你少走弯路。2. 概念拆解Nothing 和 DBNull 分别是什么2.1 Nothing引用类型的“默认状态”在 VB.NET 里Nothing 表示一个引用类型变量没有指向任何对象。String 类型变量未初始化时是 Nothing自定义类实例未创建时是 Nothing数组未分配时也是 Nothing。这和 C# 的 null 在绝大多数场景下等价但 VB.NET 还有一个特殊点Nothing 也可以赋给值类型前提是该值类型是可空类型。例如Dim age As Integer? Nothing这时候 age 这个盒子里面没有值而不是整数 0。你可以用 age.HasValue 来判断它是否为空。如果把 Nothing 直接赋给普通的 Integer结果会变成 0这属于 VB.NET 的隐式转换规则初学者最容易在这里懵掉。Nothing 的作用范围很广主要包括声明对象变量后在创建实例之前先置空判断某个对象是否存在可选参数的默认值清理长生命周期的对象引用让垃圾回收可以更早处理。它本质上是“语言层”的空用来表达“这个变量现在什么也不指向”。2.2 DBNull数据库三值逻辑的“代言人”DBNull.Value 是 System.DBNull 类型的一个单例实例整个进程中只有这一个实例。它的出现完全是为了数据库服务。SQL 中的 NULL 代表“未知”或“缺失”它既不是 0也不是空字符串更不是 False它是一种独立的状态。例如用户表里的“手机号”字段可能出现这三种情况用户没填写字段为 NULL用户填了但提交的是空字符串字段为 ;用户填了有效号码字段为 138...。如果 ADO.NET 把 NULL 直接映射成 Nothing你还能区分“字段为空”和“变量未赋值”吗在表层代码里也许能凑合但一旦多层传递、序列化或写入其他系统语义就容易被吞掉。所以 ADO.NET 在设计上做了隔离读取 SQL 结果集时凡是遇到 NULL一律包装成 DBNull.Value 返回。这是一个有意为之的选择不是设计缺陷。2.3 设计动机为什么不能统一成一个空理解这里的关键是要明白“语言层的空”和“数据层的空”是两种不同性质的东西。我经常给团队打比方Nothing 就像你办公桌上没有放文件DBNull 则像文件架上放了一个标签标签上写着“此文件缺失”。前者是物理状态后者是元信息。如果你的程序只需要知道“桌上有没有文件”用 Nothing 就够但如果你的程序还要向上级汇报“缺失了多少份文件”你就必须保留 DBNull 这个状态不能把它降级成 Nothing。在财务、医疗、统计类系统里NULL 经常代表特殊业务含义。比如某个费用字段如果是 NULL表示该费用尚未核定如果是 0表示核定结果为 0。如果统一用了 Nothing后续处理时你根本分不清这两者报表统计会失真。所以一个合格的数据访问层必须尊重 DBNull.Value而不是在入口处粗暴地把所有“空”都归一化成 Nothing。3. 判断与比较常用写法与底层差异3.1 用 Is 而不是等于号这是最容易踩的语法坑。判断 Nothing 的标准写法是If obj Is Nothing Then判断 DBNull 的标准写法是If obj Is DBNull.Value Then为什么不能用等号因为无论是 Nothing 还是 DBNull.Value都不是普通“值”。Nothing 本身不是一个实例DBNull.Value 是一个对象引用。等号比较在 VB.NET 里走的是“值相等”的语义而这两个东西的“值”定义很模糊编译器虽然在某些场景下允许你写 obj Nothing但带来的可读性代价很大。我自己在 Code Review 时只要看到 Nothing 或 Nothing 写法的基本都会建议改成 Is 或 IsNot。不是为了炫技而是因为 Is 一眼就能让人明白这是在比较引用状态减少误读。3.2 DBNull.Value 的单例特性DBNull.Value 是单例这个特性让引用比较变得非常可靠。你不需要担心“两个 DBNull.Value 实例内容相同但引用不同”的问题因为进程内根本不会存在第二个实例。正因如此以下写法是安全且高效的If value Is DBNull.Value Then这条规则同样适用于从 DataRow 拿到的字段对象。不过 DataRow 本身还提供了更便捷的 IsNull 方法If row.IsNull(Remark) Then它会帮你封装对 DBNull.Value 的判断代码更简洁。如果你的开发环境比较老仍然使用 DataSet 和 DataTable 这一套建议优先用 row.IsNull。3.3 TypeOf 与 GetType 的兜底场景有时候你面对的对象来路不明可能是 Nothing可能是 DBNull.Value也可能是别的类型。这时候判断写起来要小心。我推荐用 TypeOfIf TypeOf value Is DBNull ThenTypeOf 表达式在 value 为 Nothing 时会返回 False不会抛异常所以你可以放心拿它做兜底判断。相比之下下面这种写法就要谨慎If value.GetType() GetType(DBNull) Then如果 value 是 Nothing这行代码会直接抛出 NullReferenceException。非要这么写前面得先补一个 Is Nothing 判断。这种做法我见过很多次每次都是线上报异常之后才被发现所以这里专门提醒一下。3.4 四种判断方式对比判断写法适用场景注意事项obj Is Nothing引用类型或可空值类型语义清晰推荐优先使用obj Is DBNull.ValueDataReader、参数对象等DBNull.Value 是单例比较安全row.IsNull(列名)DataRow 读字段封装好 DBNull 判断代码最简洁TypeOf obj Is DBNull对象类型未知的兜底场景对 Nothing 友好不会抛异常联合起来看其实每一种写法都有清晰的使用边界不需要死记硬背只要想清楚“我现在面对的是数据层的空还是语言层的空”自然就能选对。4. 数据访问实战从 DataReader 到参数写入4.1 读取 DataReader 时到底发生了什么SqlDataReader 是高频使用的读取方式。当某列为 NULL 时reader(列名) 返回的不是 Nothing也不是空字符串而是 DBNull.Value。由于索引器的返回类型是 Object你不做转换和判断直接赋给 String 变量Option Strict On 的项目会直接编译报错Dim name As String reader(Name)有些团队为了图省事把 Option Strict 关掉这种代码能编译过但运行时的语义依旧混乱。遇到 NULL 时你将一个 DBNull 对象塞进 String 变量大概率会在后续处理里产生意外。正确姿势是先判断再取值Dim name As String If Not IsDBNull(reader(Name)) Then name CStr(reader(Name)) End If如果你追求性能可以用 GetOrdinal 先拿列索引再用类型化 GetString 读取Dim nameIndex As Integer reader.GetOrdinal(Name) Dim name As String If Not reader.IsDBNull(nameIndex) Then name reader.GetString(nameIndex) End If这种写法不会经历 Object 装箱和拆箱在高频读取场景下效果更明显。缺点是比较啰嗦所以我通常建议把它封装成一个通用辅助函数见第 6 节。4.2 写入参数时如何不把 NULL 搞丢写入数据库时很多人反过来栽跟头。比如界面上文本框为空业务上希望插入 NULL于是有人直接写cmd.Parameters.Add(Remark, SqlDbType.NVarChar, 500).Value remark如果 remark 变量是 Nothing某些数据库驱动可能不会把它当作 SQL NULL 写入而是当作“参数未提供”。表现就是插入失败、参数默认值生效或者意外写入空字符串。正确的做法是明确把空值映射成 DBNull.ValueDim remarkValue As Object If String.IsNullOrEmpty(remark) Then remarkValue DBNull.Value Else remarkValue remark End If cmd.Parameters.Add(Remark, SqlDbType.NVarChar, 500).Value remarkValue还可以用三元 If 表达式简化cmd.Parameters.Add(Remark, SqlDbType.NVarChar, 500).Value If(String.IsNullOrEmpty(remark), DBNull.Value, remark)但这里有个地方要留意If 操作符的两个分支返回类型要兼容。DBNull.Value 是 Objectremark 是 StringVB.NET 会做类型统一最终作为 Object 赋值给参数所以这种写法是安全的。如果你的项目用的是 AddWithValue最好确认一下列的类型和长度避免因 nvarchar 长度推断问题影响查询计划复用。4.3 DataRow 与 DataTable 的读法DataSet 时代的老代码大量使用 DataRow 判断空值。推荐写法是If row.IsNull(Phone) Then phone Else phone row(Phone).ToString() End If也可以用短一点的三元表达式Dim phone As String If(row.IsNull(Phone), , row(Phone).ToString())这里值得展开一点为什么不能用 row(Phone).ToString() 直接兜底因为 DBNull.Value.ToString() 返回的是空字符串程序不会报错这也导致很多人没察觉问题。但你的业务如果必须区分“数据库里是 NULL”和“数据库里是空字符串”这种写法就会丢信息。比如你看一个用户是否填写了紧急联系人紧急联系人为 NULL 表示完全没填为 可能表示填了但清空过如果统一成空字符串后台导出报表时统计会出错。4.4 ORM 与原生态 SQL 并存时的注意点现在不少新项目会引入 ORM比如某些轻量级框架。ORM 在实体属性上通常用可空类型来表示数据库 NULLString? 或 Integer? 在代码里可以直接用 Nothing 判断。这一点确实省心因为 ORM 在映射时已经把 DBNull.Value 转换成了 Nothing。但隐患在于只要项目里存在原生 SQL、存储过程、视图或第三方报表组件DBNull.Value 就还会出现。我曾经排查过一个奇怪问题存储过程返回的统计值为 NULL到了实体里变成了 0前端展示也没错可是另一个系统通过接口订阅这份数据时始终无法区分“结果为 0”和“没有结果”。最后定位发现是中间层的通用转换函数把所有 DBNull.Value 都强转成了 0。我的建议很简单即使使用 ORM也要保留一套处理 DBNull.Value 的工具函数避免在项目边界上丢失数据库空值的语义。这不算额外负担只是给未来少埋几个雷。5. 常见误区与排查实录5.1 用 Nothing 判断数据库空值分支永远进不去这是最常见的一种。原因前面已经讲过数据库 NULL 读出来是 DBNull.Value不是 Nothing。错误代码If dr(Score) Is Nothing Then score 0 Else score CDec(dr(Score)) End If正确代码If Not IsDBNull(dr(Score)) Then score CDec(dr(Score)) Else score 0 End If排查这类问题时最快的办法是在判断之前临时输出对象的类型Console.WriteLine(dr(Score).GetType())一旦你看到输出 System.DBNull问题根源基本就锁定了。5.2 DBNull.Value.ToString() 返回空字符串的迷惑性如果你在代码里写了 result someObject.ToString()而 someObject 恰好是 DBNull.Value这个调用不会抛异常返回的是 String.Empty。表面上看程序“没有 bug”但本质是空值信息被静默吞掉了。这个坑很隐蔽尤其是数据清洗、批量导入这类场景。某个字段为空时导出到文本文件中变成空白看起来和真正填了空字符串没有区别但业务方核对数据时发现问题你很难快速定位。我在实际处理中养成了一个习惯凡是对象类型可能是 DBNull 的地方绝对不直接 ToString而是先判断再决定默认值。5.3 把 DBNull.Value 赋给 String 变量导致类型异常在 Option Strict Off 的旧项目里类似代码可能编译通过但运行时不保证安全。我在维护一个老系统时就见过Dim customerName As String dataRow(Name)当“Name”列是 NULL 时这条赋值在某些环境会抛转型错误在另一些环境会得到空字符串。行为不一致真的很折磨人。后来团队定了规矩所有 DataRow 取字段必须走封装函数不允许直接把 Object 赋给强类型变量。5.4 通用方法收到 DBNull 参数时的失控如果你写了一些公共工具类参数类型是 Object调用方可能会把 DBNull.Value 传进来。我曾遇到过一个导入 Excel 的项目第三方组件解析空单元格时返回 DBNull.Value然后工具方法拿到它去拼接 SQL直接抛异常。这种问题在接口对接时尤其常见。解决思路是在工具方法入口做统一归一化Public Function NormalizeString(value As Object) As String If value Is Nothing OrElse value Is DBNull.Value Then Return End If Return value.ToString() End Function这方法虽然简单但能把很多隐藏问题挡在门外。5.5 常见问题速查表现象原因解决方案用 Is Nothing 判断数据库字段不生效字段 NULL 被包装成 DBNull.Value改用 IsDBNull 或 row.IsNull给 String 变量赋 reader(列名) 报错Object 转 String 在 Option Strict On 下受限先判断空值再用 CStr 或 GetString参数赋 Nothing 后数据库没写入 NULL部分驱动将 Nothing 视为未提供参数显式赋 DBNull.ValueDBNull.Value.ToString() 得到空字符串DBNull 的 ToString 实现如此先判断不要依赖 ToString 兜底对象 GetType() 抛空引用对象本身是 Nothing改用 TypeOf 判断或先判空这张表我贴在了团队内部 Wiki 上后来新同学接手数据层代码时对照着看能少踩很多坑。6. 我的实践经验与建议6.1 统一空值处理约定代码规范这东西一个人遵守没有用关键是整个团队统一。我在带队时定了几条硬性约定判断引用是否为空一律用 Is Nothing / IsNot Nothing判断数据库空值一律用 IsDBNull 或 row.IsNull写入数据库参数时所有可能为空的业务值显式映射为 DBNull.Value禁止在数据层之外出现 DBNull.Value 的裸奔传递通用辅助函数入口必须做空值归一化。这几条看起来简单但对减少低级故障很有帮助。尤其是最后一条等于给系统边界加了一层保险DBNull 即使从数据库冒出来也会在进入业务逻辑之前被转化为明确的默认值。6.2 封装一个安全读取辅助函数这是我个人推荐的一段代码别看简单实用性很强Public Shared Function GetStringValue(reader As SqlDataReader, fieldName As String) As String Dim ordinal As Integer reader.GetOrdinal(fieldName) If reader.IsDBNull(ordinal) Then Return End If Return reader.GetString(ordinal) End Function原理说明GetOrdinal 预先取列的序号避免在循环中反复按列名字符串查找性能更好。IsDBNull 判断之后再调用 GetString 时就不会碰到 DBNull 转换问题。调用方只需要一行Dim name As String GetStringValue(reader, Name)团队里如果使用 DataTable也可以封装一个 DataRow 版本Public Shared Function GetRowString(row As DataRow, columnName As String) As String If row.IsNull(columnName) Then Return End If Return row(columnName).ToString() End Function这些函数虽小但会让每天的编码工作变得安稳很多。6.3 最后说点个人体会前阵子帮一个朋友排查线上问题他写了很多年代码还是被 DBNull.Value 摆了一道。我给他看排查日志时他说了一句话让我印象很深“我一直以为 VB.NET 里空就是 Nothing没想到数据层还藏着另一个空。”其实很多 bug 并不是逻辑有多复杂而是我们对基础概念的默认假设出了问题。Nothing 和 DBNull 的区别一句话能讲完但真正把它落实到每一个读写场景需要靠经验和纪律。我个人的习惯是拿到任何一段数据访问代码先问自己三个问题——这个变量可能处于什么状态数据库里那个字段是否允许 NULL如果允许我在代码里有没有显式处理想清楚这三件事大半空值相关的坑都能绕开。如果你正在写 VB.NET 的数据层建议把这篇文章提到的判断方式和封装函数直接拿过去用遇到问题再回来对照速查表应该能省下不少排查时间。