标题本身看着简单但真正在项目里遇到问题的时候很多人会在这两个方法上栽跟头。我先把话放在前面ObjectUtil.isNotNull只管对象引用是否指向了null而ObjectUtil.isNotEmpty关心的是对象“有没有实际内容”。这两个语义层次完全不同却在日常代码里被频繁混用。这篇就围绕它俩的源码逻辑、真实场景选型、横向工具库对比和踩坑经验展开适合刚接触Hutool的Java开发者也适合写了很多年代码但没细究过工具方法语义的中级工程师。我会按排查实战的方式把问题掰开揉碎讲清楚。1. 先把概念理清null、空字符串和“空内容”不是一码事1.1 从一场“空字符串放行”的线上问题说起先说一个我实际遇到过的案例。一个回调接口接收上游平台推送的用户昵称代码写的是if (ObjectUtil.isNotNull(nickname)) { sendWelcomeMessage(nickname); }测试环境一切正常因为测试用例传的大多是null或者完整的昵称。结果上了生产一部分用户收到“欢迎您”这样的消息昵称直接消失了。排查日志发现上游平台在解析JSON时如果字段缺失框架默认给赋值成空字符串而不是null。问题就出在这里ObjectUtil.isNotNull()返回的是true因为空字符串在JVM里是一个真实存在的对象它的引用不是null只是这个对象内部长度为0。于是代码认为“昵称不为空”走进了发消息的逻辑最后拼出一个只有半句话的文案。这个案例给我最大的教训是isNotNull解决的是“引用是否存在”的问题isNotEmpty才解决“内容是否可用”的问题。如果当时写的是ObjectUtil.isNotEmpty(nickname)空字符串就会被拦截下来。这也引出了本篇文章要重点分析的两个方法的核心差异。1.2 null、空串、空白串在JVM层面的本质区别为了搞清楚这两个方法先得把几个概念放在一起对比。很多人以为null和差不多其实差别极大。null表示“引用不指向任何对象”它不占堆内存调用任何实例方法都会抛NullPointerException。而是一个长度为0的字符串对象它已经完成了实例化占据堆内存可以正常调用length()、isEmpty()、equals()等方法。至于 它是一个长度为1的字符串对象里面装着一个空格字符既不是null也不是长度为0。待判断的值是否null字符串长度ObjectUtil.isNotNullObjectUtil.isNotEmpty常见来源null是无falsefalse数据库NULL、接口未传参否0truefalseJSON字段缺失、前端清空输入框 否1truetrue用户误输入空格、参数拼接残留abc否3truetrue正常业务数据new ArrayList()否无0个元素truefalse查无数据的空集合返回new Object()否无truetrue普通对象实例这个表格建议大家收藏。它清晰展示了为什么isNotNull和isNotEmpty经常出现“一个放行、一个拦截”的分歧。本质上isNotEmpty是在isNotNull的基础上又追加了一层“内容非空”的校验。1.3 “非空”的反面并不只是null注意一个逻辑陷阱!ObjectUtil.isNotEmpty(x)并不等价于x null。它包含两种可能一种是x本身就是null另一种是x虽然有引用但内容是空的比如空字符串、空集合、空Map。很多bug的根因就是开发者把这两者画了等号。我见过最典型的一种写法if (ObjectUtil.isNotNull(str) str.length() 0) { // 业务处理 }这段代码用isNotNull加上手动判长度想表达“字符串非空”的意思。但既然这个项目已经引入了Hutool为什么不直接写ObjectUtil.isNotEmpty(str)呢不仅代码更短而且语义更完整。理解这一点是后续所有选型和避坑的基础。2. 源码拆解ObjectUtil.isNotNull和isNotEmpty到底做了什么2.1 isNotNull的源码逻辑与JVM语义先把Hutool中ObjectUtil的isNotNull源码亮出来它简单到让人怀疑人生public static boolean isNotNull(Object obj) { return null ! obj; }是的全方法就这一行。它做的是JVM层面的引用判断变量指向的内存地址是否为null。它在语义上等同于JDK自带的Objects.nonNull(obj)。因为太简单很多人反而容易轻视它的作用。但实际上它是所有非空判断体系里的地基。判断一个对象是否已经完成初始化、是否可以从第三方接口返回后直接调用其方法这些场景里isNotNull都是最恰当的工具。比如User user userService.getById(userId); if (ObjectUtil.isNotNull(user)) { return user.getName(); }这里只要保证user不是null就可以安全调用实例方法。至于user.getName()返回的是不是null那是另一个维度的判断不该让ObjectUtil.isNotNull去越权管理。2.2 isNotEmpty的判定树从CharSequence到OptionalisNotEmpty并不是很多新手以为的“非null对象就返回true”。它内部有一棵完整的类型判定树。以Hutool 5.x版本的ObjectUtil.isEmpty为例源码逻辑大概是public static boolean isEmpty(Object obj) { if (null obj) { return true; } else if (obj instanceof CharSequence) { return 0 ((CharSequence) obj).length(); } else if (obj instanceof Map) { return ((Map?, ?) obj).isEmpty(); } else if (obj instanceof Iterable) { return false ((Iterable?) obj).iterator().hasNext(); } else if (obj instanceof Iterator) { return false ((Iterator?) obj).hasNext(); } else if (ArrayUtil.isArray(obj)) { return ArrayUtil.isEmpty(obj); } else if (obj instanceof Optional) { return false ((Optional?) obj).isPresent(); } return false; } public static boolean isNotEmpty(Object obj) { return false isEmpty(obj); }把这个判定树拆开看每一层都有自己的职责CharSequence分支包括String、StringBuilder、StringBuffer等。判断标准是length() 0。注意这里只看长度不看内容所以 会被判定为非空。Map分支判断isEmpty()也就是键值对数量是否为0。Iterable分支包括所有Collection以及自定义实现了Iterable的类。判定方式不是调用isEmpty()而是看iterator().hasNext()。Iterator分支直接看迭代器是否还有下一个元素。数组分支通过ArrayUtil.isArray识别兼容基本类型数组和对象数组然后判断数组长度。Optional分支判断是否存在值等价于isPresent()。兜底return false如果对象不属于上述任何JDK常见容器类型框架默认认为它“非空”。这个兜底逻辑很重要。它意味着ObjectUtil.isNotEmpty(123)返回的是trueObjectUtil.isNotEmpty(new Object())也是true。因为这个方法压根没有为普通对象定义“空”的概念只能默认它非空。2.3 两个方法的从属关系与等价变形一句话总结从属关系isNotEmpty是isNotNull的超集校验。所有能通过isNotEmpty的对象一定先通过isNotNull但isNotNull放行的对象未必能通过isNotEmpty。用等价写法表示// 对字符串而言以下两种判断完全等价 ObjectUtil.isNotEmpty(str) str ! null str.length() 0 // 对集合而言以下两种判断几乎等价 ObjectUtil.isNotEmpty(list) list ! null list.iterator().hasNext()搞清楚这层关系之后很多代码都可以简化。比如if (obj ! null !ObjectUtil.isEmpty(obj)) { // 老旧写法 } if (ObjectUtil.isNotEmpty(obj)) { // 简化写法 }所以当你在代码审查里看到有人写了if (x ! null x.length() 0)或者if (x ! null !x.isEmpty())的时候基本可以判断对方对工具类的认知还停留在手写判断阶段没有理解ObjectUtil.isNotEmpty的定位。3. 方法本身的边界决定了它得配合业务语义选型3.1 判断“对象是否存在”时用isNotNull在实际业务里isNotNull最适合的场景是“判断对象引用是否可用”而不是“判断内容是否有意义”。举几个我在项目里常用的场景判断一个Bean是否从Spring容器中成功获取。判断RPC接口返回的实体对象是否为null为null则走降级逻辑。判断MQ消息体是否为空为空则丢弃消息。这些场景共同的特点是只要对象引用存在后续逻辑就可以成立。比如一个订单实体从数据库查出来只要它不是null就可以继续做金额计算、状态流转。订单对象内部某个字段是不是空字符串那是另一层校验不在isNotNull的职责范围内。3.2 判断“字符串是否有内容”时用isNotEmpty如果是判断字符串参数是否可用来拼接、比较、入库那么isNotEmpty是比isNotNull更可靠的选择。最常见的是配置类场景。比如从配置中心读取签约回调地址String callbackUrl configService.getConfig(pay.callbackUrl); if (ObjectUtil.isNotEmpty(callbackUrl)) { // 发起回调通知 }如果配置中心返回的是null说明配置项没设置如果返回的是空字符串说明配置项被清空过。这两种情况都不该发起回调。isNotEmpty能同时拦截这两个问题。而如果写isNotNull配置项被清空成后照样会发起回调打到一堆空地址上。3.3 判断集合和Optional时建议换工具类尽管ObjectUtil.isNotEmpty能判断Map、Collection、数组但我自己在实际项目里更倾向于用专门的工具类。原因很简单代码要自解释。// 用ObjectUtil if (ObjectUtil.isNotEmpty(userList)) { // 处理用户列表 } // 用CollUtil if (CollUtil.isNotEmpty(userList)) { // 处理用户列表 }两段代码返回结果基本一致但读起来感觉完全不同。CollUtil.isNotEmpty一看就知道这是个集合类型判断ObjectUtil.isNotEmpty则让人需要停下来想一下userList到底是不是String是不是Map类型判断会不会走错分支同样的道理适用于Optional。Hutool虽然对Optional也做了分支但更推荐直接使用JDK原生APIif (optionalUser.isPresent()) { User user optionalUser.get(); }工具方法再多也不如原生语法语义清晰。这不是否定ObjectUtil而是强调一个原则能用专用工具表达清楚的地方就不要用通用工具增加阅读负担。3.4 “用错方法导致下载文件名丢失”的完整复盘再分享一个我做过完整Cause Analysis的问题。原始代码如下String fileName request.getParameter(fileName); if (ObjectUtil.isNotNull(fileName)) { response.setHeader(Content-Disposition, attachment;filename fileName); }测试步骤是正常请求fileName传了一个真实的文件名一切正常。但线上某个调用方用脚本发请求时省略了fileName参数框架解析后得到的是而不是null。ObjectUtil.isNotNull()放行后Content-Disposition头被设置成attachment;filename浏览器下载了一个没有文件名的文件看起来像丢失了下载内容。代码版本判断逻辑空串时表现空格串时表现正常文件名时表现v1ObjectUtil.isNotNull(fileName)放行错误放行错误正常v2ObjectUtil.isNotEmpty(fileName)拦截正确放行可能有隐患正常v3StrUtil.isNotBlank(fileName)拦截正确拦截正确正常最终我把代码改成了第三版因为下载文件名这个场景里用户输入一个全空格的文件名同样没有意义。这个复盘说明了一个道理方法选型不是看“哪个方法名更好”而是看“业务上什么样的值算有效”。4. 工具库对比Hutool之外其它常见库的相同方法有什么差异4.1 commons-lang3StringUtils和ObjectUtils的分工Apache commons-lang3是Java项目里另一个高频工具库。它没有ObjectUtil这个类但有两个容易对标的方法类StringUtils和ObjectUtils。StringUtils.isEmpty(str)等价于str null || str.length() 0StringUtils.isNotEmpty(str)是它的取反。不过在commons-lang3里我更推荐StringUtils.isNotBlank(str)因为它会额外把 这类空白字符串也判定为空。这在处理用户输入、请求参数时特别有用。commons-lang3的ObjectUtils.isEmpty(Object obj)在较新版本中也覆盖了数组、Collection、Map、Optional等类型的判空逻辑思路和Hutool的ObjectUtil很像。但有个细节要注意一些老版本对Optional没有专门的空值分支ObjectUtils.isEmpty(Optional.empty())可能返回false因为Optional对象本身不是null。如果你的项目依赖的commons-lang3版本较老使用前一定要确认版本行为。4.2 Spring的ObjectUtils只有isEmpty没有isNotEmptySpring框架自带的org.springframework.util.ObjectUtils也是命中率很高的工具类。它和Hutool最大的区别是Spring只有isEmpty没有isNotEmpty。你需要非空判断就得写!ObjectUtils.isEmpty(obj)。Spring的isEmpty判空范围覆盖了Optional、CharSequence、数组含基本类型数组、Collection和Map逻辑上比Hutool更保守一些。由于Spring项目基本必然引入spring-core所以很多人直接用它不额外引入Hutool。这也是一种可行的技术选型关键看团队依赖情况。4.3 JDK原生API与工具类的关系其实不用工具类也能完成所有判断但代码会变得很零碎if (list ! null list.size() 0) { // 判断非空集合 } if (str ! null str.length() 0) { // 判断非空字符串 }JDK 7之后有了Objects.isNull和Objects.nonNullJDK 11之后String.isBlank()也能判断空白字符串。原生API足够用但问题是写法太多样团队里十个人可能写出十种风格。工具类的核心价值不是“能做这件事”而是“把判断逻辑统一成一套方法统一一套语义”。4.4 横向对比表与混用风险我把常见工具库的判空方法汇总成一张表方便你平时查阅。工具库判空方法判定范围使用建议Hutool ObjectUtilisEmpty/isNotEmptyCharSequence、Map、Iterable、Iterator、数组、Optional通用兜底但更建议用专用工具Hutool StrUtilisEmpty/isNotEmpty/isBlank/isNotBlank仅String及其子类字符串判断首选Hutool CollUtilisEmpty/isNotEmpty/isBlankCollection、Iterator、Iterable、Map、数组集合判断首选commons-lang3 StringUtilsisEmpty/isNotEmpty/isBlank/isNotBlank仅String及其子类无Hutool时的字符串首选commons-lang3 ObjectUtilsisEmpty/isNotEmpty数组、Collection、Map、Optional等注意版本差异确认Optional支持Spring ObjectUtilsisEmptyOptional、CharSequence、数组、Collection、Map无isNotEmpty需要取反JDK原生Objects.isNull/nonNull/String.isEmpty单一类型简单场景可用但风格不统一提到混用风险我特别有感触。有一个项目里A同事用Hutool的ObjectUtil.isNotEmpty(userList)判断集合B同事用commons-lang3的CollectionUtils.isNotEmpty(userList)C同事自己写userList ! null userList.size() 0。三个判断在绝大多数情况下结果一致但一旦遇到特殊实现类或者Optional包装行为就可能出现分歧。代码审查时还要频繁翻看引用的是哪个包成本非常高。所以工具库的选择和判空方法的风格一定要在团队层面定下来。5. 实战中那些和isNotEmpty/isNotNull纠缠的坑5.1 空格字符串isNotEmpty不等于isNotBlank这是整个工具方法体系里最经典、踩的人最多的一个坑。isNotEmpty对字符串只判断长度是否为0它不关心字符串内容是什么。所以 的长度是1isNotEmpty( )返回true。这在很多业务场景里是不符合预期的。举个例子用户提交邀请码String inviteCode userInput.trim(); if (ObjectUtil.isNotEmpty(inviteCode)) { verifyInviteCode(inviteCode); }如果用户输入了三个空格trim之后还是空字符串但此时长度为0isNotEmpty能拦住。但如果代码忘了trim 就会通过判断拿着三个空格去查数据库、查缓存验证失败后返回一个莫名其妙的“邀请码错误”提示。正确的做法是if (StrUtil.isNotBlank(inviteCode)) { verifyInviteCode(inviteCode.trim()); }isNotBlank会先剔除首尾空白再判断长度是否大于0。所以isNotBlank( )返回false而isNotEmpty( )返回true。凡是业务上要求“用户必须输入有意义内容”的场景比如用户名、手机号、地址、搜索关键字都应该优先考虑isNotBlank。5.2 集合“非空”和“元素有效”是两回事ObjectUtil.isNotEmpty(list)或者CollUtil.isNotEmpty(list)只能告诉你集合里有元素但它不能告诉你元素本身是否合法。一个典型的线上问题长这样ListString ids getIdsFromRequest(); if (CollUtil.isNotEmpty(ids)) { batchDeleteByIds(ids); }请求方传了一个数组[]数组长度为1集合非空判断通过了。但里面的唯一元素是空字符串批量删除的时候拼出的SQL条件变成了WHERE id IN ()什么都没删掉接口却返回了“删除成功”。测试同学只验证了“传空数组接口不报错”没有验证“传只有一个空字符串的数组会怎样”。正确的姿势是集合非空和元素校验分开做ListString ids getIdsFromRequest(); boolean hasValidId CollUtil.isNotEmpty(ids) ids.stream().anyMatch(StrUtil::isNotBlank); if (hasValidId) { ListString validIds ids.stream() .filter(StrUtil::isNotBlank) .collect(Collectors.toList()); batchDeleteByIds(validIds); }这个坑的本质原因是把“集合有没有元素”和“元素能不能用”混在了一个判断里。isNotEmpty管不了元素质量它只是容器层面的判空。5.3 包装类型的特殊表现Integer 0不是空另一个反直觉的点是包装类型的判空。ObjectUtil.isNotEmpty(0)返回多少很多人会下意识认为“0不就是没值吗”但正确答案是true。因为前面源码拆解时说过Integer不属于CharSequence、Map、Iterable、数组、Optional中的任何一类会走到兜底的return false也就是非空。这个分支设计对普通对象合理但对包装类却有业务陷阱。考虑一个积分查询接口Integer points userService.getPoints(userId); if (ObjectUtil.isNotEmpty(points)) { // 展示积分但0分也会走进来 }points 0时isNotEmpty返回true代码认为“有积分”但实际上业务想要表达的是“用户没有获得过积分”。如果你要让0分和null都走“无积分”逻辑得自己封装public static boolean hasPositivePoints(Integer points) { return points ! null points 0; }同理BigDecimal.ZERO、Boolean.FALSE、Long 0L这些“业务意义上的空值”ObjectUtil.isNotEmpty统统管不了。凡是遇到包装类型请老老实实写null判断或者根据业务定义写条件判断不要指望通用工具方法替你理解业务。5.4 取反、三元表达式和连环判断里的坏味道先说取反。很多人习惯用if (!ObjectUtil.isNotEmpty(x))表达“为空”的意思但更好的写法是直截了当用ObjectUtil.isEmpty(x)。语义更顺也避免双重否定带来的阅读障碍。尤其在一个判断表达式里同时出现!isNotNull和isNotEmpty读代码的人基本要停下来画逻辑图。另一个坏味道出现在三元表达式里String displayName ObjectUtil.isNotEmpty(name) ? name : 匿名用户;这个写法的意图是“名字有值就用名字没值就显示匿名用户”。但前面提到过name 时isNotEmpty返回true所以displayName会是一个全空格字符串依旧不是有效名字。这里如果要真的拦截所有无意义值应该用StrUtil.isNotBlank(name)。还有连环判断的场景if (ObjectUtil.isNotNull(order) ObjectUtil.isNotEmpty(order.getRemark())) { log.info(订单备注{}, order.getRemark()); }这段代码逻辑没有错但可以不经过isNotNull直接写isNotEmpty因为isNotEmpty内部已经包含了null判断。这种冗余判断不会出问题但会让代码变长、变绕。我在code review时看到这类写法一般会建议删除多余的isNotNull前置判断。6. 我在项目里沉淀下来的使用规范与封装建议6.1 五条可以落地的代码规范经过几次线上问题和大量code review之后我在团队里定了几条关于判空的规范现在项目里很少再因为空判断打架了。分享出来供你参考字符串内容判空默认使用StringUtils/StringUtil的isNotBlank。只有明确知道业务上不允许空白但允许空串时才用isNotEmpty。判断对象引用是否存在使用Objects.nonNull或ObjectUtil.isNotNull。不要把isNotEmpty用在普通对象、Integer、Long、BigDecimal上否则会得到业务无关的true。集合判空使用CollUtil.isNotEmpty不要用ObjectUtil.isNotEmpty。代码自解释review时不用猜类型。一个方法内不要混用多套工具库。要么统一Hutool要么统一commons-lang3要么统一原生JDK混用的坏处是行为不一致且审查困难。包装类型的业务空值必须封装成带业务语义的方法。比如isNullOrZero、isPositive、hasValidId禁止裸写ObjectUtil.isNotEmpty(sceneId)这种既依赖方法语义又依赖业务规则的不稳定代码。6.2 一个推荐的公共方法封装示例基于上面的规范我通常会建一个BizCheckUtil之类的类把高频的“业务判空”沉淀为语义明确的静态方法。这样比散落各处使用ObjectUtil可控得多public final class BizCheckUtil { private BizCheckUtil() { } public static boolean isNullOrEmpty(String str) { return str null || str.length() 0; } public static boolean isNullOrBlank(String str) { return str null || str.trim().length() 0; } public static boolean isNullOrEmpty(Collection? collection) { return collection null || collection.isEmpty(); } public static boolean isNullOrEmpty(Map?, ? map) { return map null || map.isEmpty(); } public static boolean isNullOrZero(Integer value) { return value null || value 0; } public static boolean isNullOrZero(Long value) { return value null || value 0L; } public static boolean hasText(String str) { return str ! null str.trim().length() 0; } }有了这层封装业务代码里基本不需要再出现ObjectUtil.isNotEmpty(sceneId)这种模棱两可的写法了。每个方法的名字都在表达业务意图后来维护的人看得懂也不容易再用错。6.3 关于这两个方法我最后想说的话如果只看方法名isNotEmpty和isNotNull像是同一件事的两种叫法但只要经历过一次空字符串导致的线上问题就会明白它们分属不同的语义层次。isNotNull判断的是“这个引用有没有指向一个对象”isNotEmpty判断的是“这个对象是否承载了有效内容”。选错方法不是语法错误代码能通过编译测试用例也可能全部通过但它会在某个边界数据到来时给你留下一张很难看的日志截图。我在实际项目里的体会是工具类越通用使用前越要想想它的边界在哪里。ObjectUtil.isNotEmpty确实强大但它不是银弹。字符串有StrUtil集合有CollUtilOptional有原生isPresent每种类型都有最贴合的判断方式。真正的高手不是背下所有API而是在写每一行判断时都知道自己正在校验哪一层语义。希望这篇分析能帮你少踩几个坑至少在下次code review时能一眼看出isNotNull(str)后面还缺一个长度判断。
Hutool ObjectUtil isNotNull与isNotEmpty：从源码到实战的判空全解析
标题本身看着简单但真正在项目里遇到问题的时候很多人会在这两个方法上栽跟头。我先把话放在前面ObjectUtil.isNotNull只管对象引用是否指向了null而ObjectUtil.isNotEmpty关心的是对象“有没有实际内容”。这两个语义层次完全不同却在日常代码里被频繁混用。这篇就围绕它俩的源码逻辑、真实场景选型、横向工具库对比和踩坑经验展开适合刚接触Hutool的Java开发者也适合写了很多年代码但没细究过工具方法语义的中级工程师。我会按排查实战的方式把问题掰开揉碎讲清楚。1. 先把概念理清null、空字符串和“空内容”不是一码事1.1 从一场“空字符串放行”的线上问题说起先说一个我实际遇到过的案例。一个回调接口接收上游平台推送的用户昵称代码写的是if (ObjectUtil.isNotNull(nickname)) { sendWelcomeMessage(nickname); }测试环境一切正常因为测试用例传的大多是null或者完整的昵称。结果上了生产一部分用户收到“欢迎您”这样的消息昵称直接消失了。排查日志发现上游平台在解析JSON时如果字段缺失框架默认给赋值成空字符串而不是null。问题就出在这里ObjectUtil.isNotNull()返回的是true因为空字符串在JVM里是一个真实存在的对象它的引用不是null只是这个对象内部长度为0。于是代码认为“昵称不为空”走进了发消息的逻辑最后拼出一个只有半句话的文案。这个案例给我最大的教训是isNotNull解决的是“引用是否存在”的问题isNotEmpty才解决“内容是否可用”的问题。如果当时写的是ObjectUtil.isNotEmpty(nickname)空字符串就会被拦截下来。这也引出了本篇文章要重点分析的两个方法的核心差异。1.2 null、空串、空白串在JVM层面的本质区别为了搞清楚这两个方法先得把几个概念放在一起对比。很多人以为null和差不多其实差别极大。null表示“引用不指向任何对象”它不占堆内存调用任何实例方法都会抛NullPointerException。而是一个长度为0的字符串对象它已经完成了实例化占据堆内存可以正常调用length()、isEmpty()、equals()等方法。至于 它是一个长度为1的字符串对象里面装着一个空格字符既不是null也不是长度为0。待判断的值是否null字符串长度ObjectUtil.isNotNullObjectUtil.isNotEmpty常见来源null是无falsefalse数据库NULL、接口未传参否0truefalseJSON字段缺失、前端清空输入框 否1truetrue用户误输入空格、参数拼接残留abc否3truetrue正常业务数据new ArrayList()否无0个元素truefalse查无数据的空集合返回new Object()否无truetrue普通对象实例这个表格建议大家收藏。它清晰展示了为什么isNotNull和isNotEmpty经常出现“一个放行、一个拦截”的分歧。本质上isNotEmpty是在isNotNull的基础上又追加了一层“内容非空”的校验。1.3 “非空”的反面并不只是null注意一个逻辑陷阱!ObjectUtil.isNotEmpty(x)并不等价于x null。它包含两种可能一种是x本身就是null另一种是x虽然有引用但内容是空的比如空字符串、空集合、空Map。很多bug的根因就是开发者把这两者画了等号。我见过最典型的一种写法if (ObjectUtil.isNotNull(str) str.length() 0) { // 业务处理 }这段代码用isNotNull加上手动判长度想表达“字符串非空”的意思。但既然这个项目已经引入了Hutool为什么不直接写ObjectUtil.isNotEmpty(str)呢不仅代码更短而且语义更完整。理解这一点是后续所有选型和避坑的基础。2. 源码拆解ObjectUtil.isNotNull和isNotEmpty到底做了什么2.1 isNotNull的源码逻辑与JVM语义先把Hutool中ObjectUtil的isNotNull源码亮出来它简单到让人怀疑人生public static boolean isNotNull(Object obj) { return null ! obj; }是的全方法就这一行。它做的是JVM层面的引用判断变量指向的内存地址是否为null。它在语义上等同于JDK自带的Objects.nonNull(obj)。因为太简单很多人反而容易轻视它的作用。但实际上它是所有非空判断体系里的地基。判断一个对象是否已经完成初始化、是否可以从第三方接口返回后直接调用其方法这些场景里isNotNull都是最恰当的工具。比如User user userService.getById(userId); if (ObjectUtil.isNotNull(user)) { return user.getName(); }这里只要保证user不是null就可以安全调用实例方法。至于user.getName()返回的是不是null那是另一个维度的判断不该让ObjectUtil.isNotNull去越权管理。2.2 isNotEmpty的判定树从CharSequence到OptionalisNotEmpty并不是很多新手以为的“非null对象就返回true”。它内部有一棵完整的类型判定树。以Hutool 5.x版本的ObjectUtil.isEmpty为例源码逻辑大概是public static boolean isEmpty(Object obj) { if (null obj) { return true; } else if (obj instanceof CharSequence) { return 0 ((CharSequence) obj).length(); } else if (obj instanceof Map) { return ((Map?, ?) obj).isEmpty(); } else if (obj instanceof Iterable) { return false ((Iterable?) obj).iterator().hasNext(); } else if (obj instanceof Iterator) { return false ((Iterator?) obj).hasNext(); } else if (ArrayUtil.isArray(obj)) { return ArrayUtil.isEmpty(obj); } else if (obj instanceof Optional) { return false ((Optional?) obj).isPresent(); } return false; } public static boolean isNotEmpty(Object obj) { return false isEmpty(obj); }把这个判定树拆开看每一层都有自己的职责CharSequence分支包括String、StringBuilder、StringBuffer等。判断标准是length() 0。注意这里只看长度不看内容所以 会被判定为非空。Map分支判断isEmpty()也就是键值对数量是否为0。Iterable分支包括所有Collection以及自定义实现了Iterable的类。判定方式不是调用isEmpty()而是看iterator().hasNext()。Iterator分支直接看迭代器是否还有下一个元素。数组分支通过ArrayUtil.isArray识别兼容基本类型数组和对象数组然后判断数组长度。Optional分支判断是否存在值等价于isPresent()。兜底return false如果对象不属于上述任何JDK常见容器类型框架默认认为它“非空”。这个兜底逻辑很重要。它意味着ObjectUtil.isNotEmpty(123)返回的是trueObjectUtil.isNotEmpty(new Object())也是true。因为这个方法压根没有为普通对象定义“空”的概念只能默认它非空。2.3 两个方法的从属关系与等价变形一句话总结从属关系isNotEmpty是isNotNull的超集校验。所有能通过isNotEmpty的对象一定先通过isNotNull但isNotNull放行的对象未必能通过isNotEmpty。用等价写法表示// 对字符串而言以下两种判断完全等价 ObjectUtil.isNotEmpty(str) str ! null str.length() 0 // 对集合而言以下两种判断几乎等价 ObjectUtil.isNotEmpty(list) list ! null list.iterator().hasNext()搞清楚这层关系之后很多代码都可以简化。比如if (obj ! null !ObjectUtil.isEmpty(obj)) { // 老旧写法 } if (ObjectUtil.isNotEmpty(obj)) { // 简化写法 }所以当你在代码审查里看到有人写了if (x ! null x.length() 0)或者if (x ! null !x.isEmpty())的时候基本可以判断对方对工具类的认知还停留在手写判断阶段没有理解ObjectUtil.isNotEmpty的定位。3. 方法本身的边界决定了它得配合业务语义选型3.1 判断“对象是否存在”时用isNotNull在实际业务里isNotNull最适合的场景是“判断对象引用是否可用”而不是“判断内容是否有意义”。举几个我在项目里常用的场景判断一个Bean是否从Spring容器中成功获取。判断RPC接口返回的实体对象是否为null为null则走降级逻辑。判断MQ消息体是否为空为空则丢弃消息。这些场景共同的特点是只要对象引用存在后续逻辑就可以成立。比如一个订单实体从数据库查出来只要它不是null就可以继续做金额计算、状态流转。订单对象内部某个字段是不是空字符串那是另一层校验不在isNotNull的职责范围内。3.2 判断“字符串是否有内容”时用isNotEmpty如果是判断字符串参数是否可用来拼接、比较、入库那么isNotEmpty是比isNotNull更可靠的选择。最常见的是配置类场景。比如从配置中心读取签约回调地址String callbackUrl configService.getConfig(pay.callbackUrl); if (ObjectUtil.isNotEmpty(callbackUrl)) { // 发起回调通知 }如果配置中心返回的是null说明配置项没设置如果返回的是空字符串说明配置项被清空过。这两种情况都不该发起回调。isNotEmpty能同时拦截这两个问题。而如果写isNotNull配置项被清空成后照样会发起回调打到一堆空地址上。3.3 判断集合和Optional时建议换工具类尽管ObjectUtil.isNotEmpty能判断Map、Collection、数组但我自己在实际项目里更倾向于用专门的工具类。原因很简单代码要自解释。// 用ObjectUtil if (ObjectUtil.isNotEmpty(userList)) { // 处理用户列表 } // 用CollUtil if (CollUtil.isNotEmpty(userList)) { // 处理用户列表 }两段代码返回结果基本一致但读起来感觉完全不同。CollUtil.isNotEmpty一看就知道这是个集合类型判断ObjectUtil.isNotEmpty则让人需要停下来想一下userList到底是不是String是不是Map类型判断会不会走错分支同样的道理适用于Optional。Hutool虽然对Optional也做了分支但更推荐直接使用JDK原生APIif (optionalUser.isPresent()) { User user optionalUser.get(); }工具方法再多也不如原生语法语义清晰。这不是否定ObjectUtil而是强调一个原则能用专用工具表达清楚的地方就不要用通用工具增加阅读负担。3.4 “用错方法导致下载文件名丢失”的完整复盘再分享一个我做过完整Cause Analysis的问题。原始代码如下String fileName request.getParameter(fileName); if (ObjectUtil.isNotNull(fileName)) { response.setHeader(Content-Disposition, attachment;filename fileName); }测试步骤是正常请求fileName传了一个真实的文件名一切正常。但线上某个调用方用脚本发请求时省略了fileName参数框架解析后得到的是而不是null。ObjectUtil.isNotNull()放行后Content-Disposition头被设置成attachment;filename浏览器下载了一个没有文件名的文件看起来像丢失了下载内容。代码版本判断逻辑空串时表现空格串时表现正常文件名时表现v1ObjectUtil.isNotNull(fileName)放行错误放行错误正常v2ObjectUtil.isNotEmpty(fileName)拦截正确放行可能有隐患正常v3StrUtil.isNotBlank(fileName)拦截正确拦截正确正常最终我把代码改成了第三版因为下载文件名这个场景里用户输入一个全空格的文件名同样没有意义。这个复盘说明了一个道理方法选型不是看“哪个方法名更好”而是看“业务上什么样的值算有效”。4. 工具库对比Hutool之外其它常见库的相同方法有什么差异4.1 commons-lang3StringUtils和ObjectUtils的分工Apache commons-lang3是Java项目里另一个高频工具库。它没有ObjectUtil这个类但有两个容易对标的方法类StringUtils和ObjectUtils。StringUtils.isEmpty(str)等价于str null || str.length() 0StringUtils.isNotEmpty(str)是它的取反。不过在commons-lang3里我更推荐StringUtils.isNotBlank(str)因为它会额外把 这类空白字符串也判定为空。这在处理用户输入、请求参数时特别有用。commons-lang3的ObjectUtils.isEmpty(Object obj)在较新版本中也覆盖了数组、Collection、Map、Optional等类型的判空逻辑思路和Hutool的ObjectUtil很像。但有个细节要注意一些老版本对Optional没有专门的空值分支ObjectUtils.isEmpty(Optional.empty())可能返回false因为Optional对象本身不是null。如果你的项目依赖的commons-lang3版本较老使用前一定要确认版本行为。4.2 Spring的ObjectUtils只有isEmpty没有isNotEmptySpring框架自带的org.springframework.util.ObjectUtils也是命中率很高的工具类。它和Hutool最大的区别是Spring只有isEmpty没有isNotEmpty。你需要非空判断就得写!ObjectUtils.isEmpty(obj)。Spring的isEmpty判空范围覆盖了Optional、CharSequence、数组含基本类型数组、Collection和Map逻辑上比Hutool更保守一些。由于Spring项目基本必然引入spring-core所以很多人直接用它不额外引入Hutool。这也是一种可行的技术选型关键看团队依赖情况。4.3 JDK原生API与工具类的关系其实不用工具类也能完成所有判断但代码会变得很零碎if (list ! null list.size() 0) { // 判断非空集合 } if (str ! null str.length() 0) { // 判断非空字符串 }JDK 7之后有了Objects.isNull和Objects.nonNullJDK 11之后String.isBlank()也能判断空白字符串。原生API足够用但问题是写法太多样团队里十个人可能写出十种风格。工具类的核心价值不是“能做这件事”而是“把判断逻辑统一成一套方法统一一套语义”。4.4 横向对比表与混用风险我把常见工具库的判空方法汇总成一张表方便你平时查阅。工具库判空方法判定范围使用建议Hutool ObjectUtilisEmpty/isNotEmptyCharSequence、Map、Iterable、Iterator、数组、Optional通用兜底但更建议用专用工具Hutool StrUtilisEmpty/isNotEmpty/isBlank/isNotBlank仅String及其子类字符串判断首选Hutool CollUtilisEmpty/isNotEmpty/isBlankCollection、Iterator、Iterable、Map、数组集合判断首选commons-lang3 StringUtilsisEmpty/isNotEmpty/isBlank/isNotBlank仅String及其子类无Hutool时的字符串首选commons-lang3 ObjectUtilsisEmpty/isNotEmpty数组、Collection、Map、Optional等注意版本差异确认Optional支持Spring ObjectUtilsisEmptyOptional、CharSequence、数组、Collection、Map无isNotEmpty需要取反JDK原生Objects.isNull/nonNull/String.isEmpty单一类型简单场景可用但风格不统一提到混用风险我特别有感触。有一个项目里A同事用Hutool的ObjectUtil.isNotEmpty(userList)判断集合B同事用commons-lang3的CollectionUtils.isNotEmpty(userList)C同事自己写userList ! null userList.size() 0。三个判断在绝大多数情况下结果一致但一旦遇到特殊实现类或者Optional包装行为就可能出现分歧。代码审查时还要频繁翻看引用的是哪个包成本非常高。所以工具库的选择和判空方法的风格一定要在团队层面定下来。5. 实战中那些和isNotEmpty/isNotNull纠缠的坑5.1 空格字符串isNotEmpty不等于isNotBlank这是整个工具方法体系里最经典、踩的人最多的一个坑。isNotEmpty对字符串只判断长度是否为0它不关心字符串内容是什么。所以 的长度是1isNotEmpty( )返回true。这在很多业务场景里是不符合预期的。举个例子用户提交邀请码String inviteCode userInput.trim(); if (ObjectUtil.isNotEmpty(inviteCode)) { verifyInviteCode(inviteCode); }如果用户输入了三个空格trim之后还是空字符串但此时长度为0isNotEmpty能拦住。但如果代码忘了trim 就会通过判断拿着三个空格去查数据库、查缓存验证失败后返回一个莫名其妙的“邀请码错误”提示。正确的做法是if (StrUtil.isNotBlank(inviteCode)) { verifyInviteCode(inviteCode.trim()); }isNotBlank会先剔除首尾空白再判断长度是否大于0。所以isNotBlank( )返回false而isNotEmpty( )返回true。凡是业务上要求“用户必须输入有意义内容”的场景比如用户名、手机号、地址、搜索关键字都应该优先考虑isNotBlank。5.2 集合“非空”和“元素有效”是两回事ObjectUtil.isNotEmpty(list)或者CollUtil.isNotEmpty(list)只能告诉你集合里有元素但它不能告诉你元素本身是否合法。一个典型的线上问题长这样ListString ids getIdsFromRequest(); if (CollUtil.isNotEmpty(ids)) { batchDeleteByIds(ids); }请求方传了一个数组[]数组长度为1集合非空判断通过了。但里面的唯一元素是空字符串批量删除的时候拼出的SQL条件变成了WHERE id IN ()什么都没删掉接口却返回了“删除成功”。测试同学只验证了“传空数组接口不报错”没有验证“传只有一个空字符串的数组会怎样”。正确的姿势是集合非空和元素校验分开做ListString ids getIdsFromRequest(); boolean hasValidId CollUtil.isNotEmpty(ids) ids.stream().anyMatch(StrUtil::isNotBlank); if (hasValidId) { ListString validIds ids.stream() .filter(StrUtil::isNotBlank) .collect(Collectors.toList()); batchDeleteByIds(validIds); }这个坑的本质原因是把“集合有没有元素”和“元素能不能用”混在了一个判断里。isNotEmpty管不了元素质量它只是容器层面的判空。5.3 包装类型的特殊表现Integer 0不是空另一个反直觉的点是包装类型的判空。ObjectUtil.isNotEmpty(0)返回多少很多人会下意识认为“0不就是没值吗”但正确答案是true。因为前面源码拆解时说过Integer不属于CharSequence、Map、Iterable、数组、Optional中的任何一类会走到兜底的return false也就是非空。这个分支设计对普通对象合理但对包装类却有业务陷阱。考虑一个积分查询接口Integer points userService.getPoints(userId); if (ObjectUtil.isNotEmpty(points)) { // 展示积分但0分也会走进来 }points 0时isNotEmpty返回true代码认为“有积分”但实际上业务想要表达的是“用户没有获得过积分”。如果你要让0分和null都走“无积分”逻辑得自己封装public static boolean hasPositivePoints(Integer points) { return points ! null points 0; }同理BigDecimal.ZERO、Boolean.FALSE、Long 0L这些“业务意义上的空值”ObjectUtil.isNotEmpty统统管不了。凡是遇到包装类型请老老实实写null判断或者根据业务定义写条件判断不要指望通用工具方法替你理解业务。5.4 取反、三元表达式和连环判断里的坏味道先说取反。很多人习惯用if (!ObjectUtil.isNotEmpty(x))表达“为空”的意思但更好的写法是直截了当用ObjectUtil.isEmpty(x)。语义更顺也避免双重否定带来的阅读障碍。尤其在一个判断表达式里同时出现!isNotNull和isNotEmpty读代码的人基本要停下来画逻辑图。另一个坏味道出现在三元表达式里String displayName ObjectUtil.isNotEmpty(name) ? name : 匿名用户;这个写法的意图是“名字有值就用名字没值就显示匿名用户”。但前面提到过name 时isNotEmpty返回true所以displayName会是一个全空格字符串依旧不是有效名字。这里如果要真的拦截所有无意义值应该用StrUtil.isNotBlank(name)。还有连环判断的场景if (ObjectUtil.isNotNull(order) ObjectUtil.isNotEmpty(order.getRemark())) { log.info(订单备注{}, order.getRemark()); }这段代码逻辑没有错但可以不经过isNotNull直接写isNotEmpty因为isNotEmpty内部已经包含了null判断。这种冗余判断不会出问题但会让代码变长、变绕。我在code review时看到这类写法一般会建议删除多余的isNotNull前置判断。6. 我在项目里沉淀下来的使用规范与封装建议6.1 五条可以落地的代码规范经过几次线上问题和大量code review之后我在团队里定了几条关于判空的规范现在项目里很少再因为空判断打架了。分享出来供你参考字符串内容判空默认使用StringUtils/StringUtil的isNotBlank。只有明确知道业务上不允许空白但允许空串时才用isNotEmpty。判断对象引用是否存在使用Objects.nonNull或ObjectUtil.isNotNull。不要把isNotEmpty用在普通对象、Integer、Long、BigDecimal上否则会得到业务无关的true。集合判空使用CollUtil.isNotEmpty不要用ObjectUtil.isNotEmpty。代码自解释review时不用猜类型。一个方法内不要混用多套工具库。要么统一Hutool要么统一commons-lang3要么统一原生JDK混用的坏处是行为不一致且审查困难。包装类型的业务空值必须封装成带业务语义的方法。比如isNullOrZero、isPositive、hasValidId禁止裸写ObjectUtil.isNotEmpty(sceneId)这种既依赖方法语义又依赖业务规则的不稳定代码。6.2 一个推荐的公共方法封装示例基于上面的规范我通常会建一个BizCheckUtil之类的类把高频的“业务判空”沉淀为语义明确的静态方法。这样比散落各处使用ObjectUtil可控得多public final class BizCheckUtil { private BizCheckUtil() { } public static boolean isNullOrEmpty(String str) { return str null || str.length() 0; } public static boolean isNullOrBlank(String str) { return str null || str.trim().length() 0; } public static boolean isNullOrEmpty(Collection? collection) { return collection null || collection.isEmpty(); } public static boolean isNullOrEmpty(Map?, ? map) { return map null || map.isEmpty(); } public static boolean isNullOrZero(Integer value) { return value null || value 0; } public static boolean isNullOrZero(Long value) { return value null || value 0L; } public static boolean hasText(String str) { return str ! null str.trim().length() 0; } }有了这层封装业务代码里基本不需要再出现ObjectUtil.isNotEmpty(sceneId)这种模棱两可的写法了。每个方法的名字都在表达业务意图后来维护的人看得懂也不容易再用错。6.3 关于这两个方法我最后想说的话如果只看方法名isNotEmpty和isNotNull像是同一件事的两种叫法但只要经历过一次空字符串导致的线上问题就会明白它们分属不同的语义层次。isNotNull判断的是“这个引用有没有指向一个对象”isNotEmpty判断的是“这个对象是否承载了有效内容”。选错方法不是语法错误代码能通过编译测试用例也可能全部通过但它会在某个边界数据到来时给你留下一张很难看的日志截图。我在实际项目里的体会是工具类越通用使用前越要想想它的边界在哪里。ObjectUtil.isNotEmpty确实强大但它不是银弹。字符串有StrUtil集合有CollUtilOptional有原生isPresent每种类型都有最贴合的判断方式。真正的高手不是背下所有API而是在写每一行判断时都知道自己正在校验哪一层语义。希望这篇分析能帮你少踩几个坑至少在下次code review时能一眼看出isNotNull(str)后面还缺一个长度判断。
