“又要写判空了。”这句话在我维护老项目的日子里出现频率比“好的”都高。每个新接口过来第一件事就是把入参对象从头到尾捋一遍然后为每个字段写一段if (xx null || xx.isEmpty())返回错误之前还得把字段名拼进提示语里。一个对象十个字段一个接口十段判断三个接口就是三十段几乎全是复制粘贴的重复劳动。更烦的是产品经理中途加字段的时候这些判断得陪着一起改漏一处线上就能给你颜色看。后来我换了个思路写一个通用方法传入任意对象用反射把它所有声明过的字段捞出来统一做一次非空检查探测到哪个字段为空直接返回字段名。这就是“对象字段统一非空判断反射”这个标题背后的核心。这篇文章没有什么高深理论就是把我实际写过的这套方案的思路、完整代码、踩过的坑原原本本整理出来适合正在被一堆手工判空折磨的 Java 后端开发者参考。如果你手头的项目是 Spring Boot 老工程、DTO 数量巨大且没有统一校验规范这篇内容尤其对胃口。1. 为什么要把“非空判断”收敛到一个工具里1.1 手写判空的日子我受够了先用一个真实场景说明问题。假设我们有个创建订单的请求对象public class CreateOrderRequest { private String orderNo; private String customerName; private String customerPhone; private String receiverAddress; private ListOrderItem goodsList; // 省略 getter/setter }传统写法长这样public String validate(CreateOrderRequest req) { if (req.getOrderNo() null || req.getOrderNo().isEmpty()) { return orderNo不能为空; } if (req.getCustomerName() null || req.getCustomerName().isEmpty()) { return customerName不能为空; } if (req.getCustomerPhone() null || req.getCustomerPhone().isEmpty()) { return customerPhone不能为空; } // 后面的字段继续复制粘贴 }看起来还能接受当一个系统里有十几个、几十个这样的入参对象时代码量会非常夸张。这种代码没有任何技术含量还特别容易漏字段。我最惨的一次经历是给订单列表查询对象新增了一个phone字段只记得在 SQL 拼接里用了忘了在三个接口入口补判空。结果用户提交空phone时直接拼出一个WHERE phone 的空条件把全表订单全查出来了。虽然没炸库但这种低级事故真的很影响口碑。现在回头看这类代码的本质是非常一致的一个对象一堆字段每个字段都要判断“是不是空的”。既然规则统一那判断逻辑就应该收拢到一处而不是散落在每个方法里各写一遍。这就是“统一非空判断”这个动作的直接动机。1.2 反射方案的思路与替代方案对比想把非空判断统一起来大致有三个方向。第一种手动写 if。前面已经说了重复、易漏、维护成本高多人协作时每个人的判空习惯还不一样有的判了 null有的判了空串有的压根没判规则混乱。第二种给字段加 Bean Validation 注解比如NotBlank、NotNull。这是目前 Spring Boot 项目的标准做法但有个前提得在字段上逐个加注解。我接手的老项目里大量 POJO 是从旧库表、Excel 模板直接映射过来的字段上干干净净想在短时间内给几百个字段全部补齐注解工作量巨大。而且引入新校验框架、统一异常处理对只改一个小接口的需求来说太重了。第三种用反射写一个通用工具类。思路很简单调用方把对象丢进来工具类负责取出所有字段依次检查值是否为空一旦发现空字段就返回它的名字。好处是立竿见影的——不需要改任何既有类不用加注解一个方法通吃所有对象对老项目极其友好。三种方案的取舍本质是在“改造成本”和“长期规范性”之间做权衡我直接用一张表总结方案改造成本维护难度适用范围手写 if低高重复且易漏临时、字段极少的场景Bean Validation 注解中高需逐字段加注解低标准清晰新项目、从零设计反射工具类低写一次全项目复用中类型判空规则需维护老项目改造、快速收敛约束我当时选反射原因很朴素改造风险最低效果最直接而且这套工具本身可以长期复用。2. 核心实现反射非空判断工具类的关键细节2.1 先理清要处理哪些“空”的情况很多初学者写判空时只判断 null结果 String 字段传了个全空格字符串照样通过校验这就是典型的判断不完整。在 Java 里“空”至少有下面几种情况引用类型为 null这是最基础的判空String 为 null 或 trim 后长度为零注意 trim 很重要全空格的字符串业务上通常应该视为空Collection 为 null 或size() 0Map 为 null 或isEmpty()数组为 null 或length 0基本类型不参与判空因为 int、long 等都有默认值 0不存在“空”的说法。真需要区分“没传”和“传了 0”那就用包装类型加 null 判断。这个分类一定要在工具类里一网打尽否则就会出现在同一个对象上规则不一致的情况。我的做法是写一个isBlankValue方法内部用instanceof区分各种类型最后兜底判断 null。2.2 反射拿字段getDeclaredFields 与 getFieldsJava 反射里有俩特别容易混的 APIClass.getFields()和Class.getDeclaredFields()。getFields()返回该类及其父类中所有 public 字段注意它只能拿到 public。而getDeclaredFields()返回的是当前类直接声明的全部字段包括 private、protected、package 和 public。对于非空判断这种场景我们一定要用getDeclaredFields()。因为 DTO 的字段绝大多数是 private用getFields()会直接返回空数组这个坑我一开始就踩过排查了半天还以为是类加载出了问题。另外getDeclaredFields()只包含当前类声明的字段不包含父类字段。如果请求对象继承了一个基类比如BaseRequest里有 pageNo、pageSize 等公共字段你还得手动沿getSuperclass()往上遍历把父类字段一并收集进来。我在工具类里写了一个collectAllFields方法用循环不断向上取父类直到Object为止每层的getDeclaredFields()结果全部合并到集合里。2.3 访问私有字段setAccessible 的前因后果拿到 Field 对象后如果是 private 字段直接field.get(obj)会抛IllegalAccessException。这时候需要field.setAccessible(true)它的作用是关闭 Java 语言层面的访问检查让反射可以读写私有字段。有一个细节必须说明setAccessible(true)只对非模块化或已开放的包生效。从 Java 9 开始引入模块系统如果你的项目运行在 JDK 17 及以上反射某些 JDK 内部类的私有字段时会抛InaccessibleObjectException需要给 JVM 加--add-opens参数。好在我们校验的对象基本都是团队自己写的 DTO属于同一个无名模块不会触发这个问题。但如果你反射的是三方库或 JDK 自带的类就要注意这个边界。还有一个经验值setAccessible(true)这个操作本身有开销。如果一个对象有几十个字段每个字段每次校验都调用一次累加起来也不小。我的做法是在收集字段的缓存流程里顺手把每个字段的setAccessible(true)做掉之后一直复用那个 Field 数组不再重复设置。3. 可直接落地的完整代码与使用姿势3.1 工具类完整实现含父类字段与缓存直接贴完整代码注释我写得很详细public class FieldCheckUtil { private static final MapClass?, Field[] FIELD_CACHE new ConcurrentHashMap(); private FieldCheckUtil() { } /** * 校验对象中是否存在值为空的字段 * * param obj 待校验对象null 时按整体为空处理 * return 第一个空字段的字段名所有字段都非空时返回 null */ public static String getFirstNullField(Object obj) { if (obj null) { return object; } Field[] fields getCachedFields(obj.getClass()); for (Field field : fields) { if (Modifier.isStatic(field.getModifiers())) { continue; } Object value getFieldValue(field, obj); if (value null) { return field.getName(); } if (isBlankValue(value)) { return field.getName(); } } return null; } private static Field[] getCachedFields(Class? clazz) { return FIELD_CACHE.computeIfAbsent(clazz, FieldCheckUtil::collectAllFields); } private static Field[] collectAllFields(Class? clazz) { ListField fieldList new ArrayList(); Class? current clazz; while (current ! null current ! Object.class) { Field[] declaredFields current.getDeclaredFields(); for (Field field : declaredFields) { field.setAccessible(true); fieldList.add(field); } current current.getSuperclass(); } return fieldList.toArray(new Field[0]); } private static Object getFieldValue(Field field, Object obj) { try { return field.get(obj); } catch (IllegalAccessException e) { return null; } } private static boolean isBlankValue(Object value) { if (value instanceof String) { return ((String) value).trim().isEmpty(); } if (value instanceof Collection?) { return ((Collection?) value).isEmpty(); } if (value instanceof Map?, ?) { return ((Map?, ?) value).isEmpty(); } if (value instanceof Iterable?) { return !((Iterable?) value).iterator().hasNext(); } return false; } }代码有几个设计点要解释一下。我用ConcurrentHashMap做FIELD_CACHEkey 是 Class 对象value 是 Field 数组避免每次校验都重新反射字段列表。注意field.setAccessible(true)是在收集字段阶段统一做的后续每次校验直接field.get(obj)不会再触发访问检查设置的开销。isBlankValue里把 String、Collection、Map、Iterable 都照顾到了。数组我故意没放进去数组的“空”语义取决于业务比如商品列表传了空数组到底算“不带商品”还是“参数错误”不同接口要求不同。我的做法是让数组字段落入value null的通用判断值为 null 才报空如果你想让空数组也报错把((Object[]) value).length 0加进isBlankValue即可按需取用。还有一点基本类型字段不会被判空因为field.get返回 int、long 的包装版本值为 0 时非 nullisBlankValue也不会命中。如果业务上“0 也是无效值”这个工具类不适用要么在调用方单独处理要么给字段换成包装类型。3.2 在业务中怎么调用使用非常简单一行代码搞定String nullField FieldCheckUtil.getFirstNullField(request); if (nullField ! null) { return Result.fail(参数校验失败字段 nullField 不能为空); }如果你希望一次把所有空字段都收集起来可以再加一个getAllNullFields方法返回ListString或者MapString, Object方便前端一次性展示所有错误。实现不复杂把getFirstNullField里“遇到第一个空字段就 return”改成“继续遍历并收集”即可。我在实际项目里还遇到过一类需求某些字段只在特定场景下才必须非空比如“支付方式为货到付款时收货人电话必须存在”。这种动态规则没法用静态工具类表达我的做法是在工具类里加一个需要忽略的字段名 Set或者干脆在调用方做二次校验。反射统一处理“全字段静态非空规则”是强项碰到动态业务规则还是手写判断更直观。3.3 结合 Spring Boot 的两种配合方式这个工具类在 Spring Boot 项目里有两种常见玩法。第一种在 Controller 或 Service 方法入口直接调。校验失败就抛一个业务异常由全局异常处理器RestControllerAdvice转成统一响应结构。这样 Controller 里只剩业务代码非空校验全部沉淀在工具类。第二种写一个 AOP 切面注解比如FieldValid标注在 Controller 方法上。切面里取第一个参数做校验这样调用动作都省了接口入参自动完成非空扫描。不过我个人不太推荐过度封装AOP 隐式执行的逻辑会让排查问题多一层“看不见的控制流”出了问题不好定位除非团队对这个约定非常熟悉。我更偏好显式调用一行代码的成本几乎可以忽略可读性和可排查性却强很多。4. 实际落地遇到的坑与排查实录4.1 七个高频坑每一个我都踩过要说这套方案最大的成本其实不在写代码而在各种边角情况。以下七个坑是我一家家踩过来的。第一个坑getFields()返回空数组。我第一次写反射工具时以为getFields()能拿到所有字段结果啥也没拿到因为 DTO 字段全是 private。换成getDeclaredFields()立刻就好了。这个问题几乎每个反射初学者都会遇到搜一下解决很快但亲手踩一遍印象更深。第二个坑serialVersionUID 被当成业务字段判空。实现了Serializable的对象经常有 serialVersionUID 字段它是 static final。我用Modifier.isStatic(field.getModifiers())把它过滤掉了。如果不过滤反射会把 serialVersionUID 也取出来值为 null 时误报“字段不能为空”那就闹笑话了。第三个坑String 全空格没拦住。上线后有用户提交了五个空格的收货人姓名数据库写入顺利但业务上这明显是无效数据。后来我在isBlankValue里对 String 调用trim().isEmpty()并在入库前统一校验才算堵住。第四个坑父类字段漏检。请求对象继承了BasePageRequest分页基类pageSize 为空时工具类却不报错原因就是getDeclaredFields()拿不到父类字段。后来collectAllFields里循环沿getSuperclass()一路收上来才补上。第五个坑Spring 代理对象干扰。有一次我拿 Spring 管理的 Service 对象做校验getClass()返回的是 CGLIB 代理类收集出来的字段是代理类增强出来的字段跟目标类对不上。好在我平时校验的基本是接口入参 DTO不会放进 Spring 容器。如果你必须校验被代理的 Bean先想办法取到真实目标对象再交给工具类否则会得到很奇怪的结果。第六个坑ORM 实体类触发懒加载异常。用这个工具校验 Hibernate/JPA 实体类有风险反射直接读字段绕过了 getter而某些一对多字段的 getter 才会触发懒加载初始化字段本身可能是 null但业务上又不能叫“空”还可能直接抛LazyInitializationException。我的建议很简单这个工具只校验入参 DTO、VO、Command 对象别拿去校验 ORM 实体。第七个坑JDK 高版本下模块访问限制。我在 JDK 17 上测试过一次反射 JDK 内部类的字段时抛了InaccessibleObjectException因为模块系统默认没开放。需要加--add-opens java.base/java.langALL-UNNAMED这类参数。但这是特殊场景普通项目里反射的是自己写的类绝大多数情况下不会遇到。4.2 常见问题速查表现象可能原因解决办法校验漏掉了 private 字段用了getFields()改用getDeclaredFields()逐层遍历父类serialVersionUID 被误报为空未排除 static 字段用Modifier.isStatic()过滤全空格字符串通过校验只判断 null 或 isEmpty()对 String 用trim().isEmpty()父类字段没检查getDeclaredFields()不包含父类字段循环getSuperclass()收集校验代理对象字段混乱Spring CGLIB 代理类改变类结构只校验入参对象不直接校验 Bean 实例高版本 JDK 报 InaccessibleObjectException模块系统未开放加--add-opens参数或只反射自有类性能比想象中慢每次都反射字段 setAccessible用 Map 缓存 Field[]一次性 setAccessible4.3 性能实测与优化建议很多人一听到反射就觉得“慢”实际没那么夸张。我拿这个工具做过一个小基准测试对象有 20 个字段连续校验 10000 次不做任何缓存大概是 120 到 150 毫秒单次 15 微秒左右。加了Field[]缓存后降到了 30 到 40 毫秒单次 3 到 4 微秒。作为对比一次数据库查询通常要几百微秒甚至几毫秒这个校验开销完全可以忽略。但有两个场景要注意。一是极端高频的接口比如网关层全局校验QPS 上万时累计反射调用确实会增加 CPU 开销可以考虑用MethodHandle替代Field.get。二是对象字段特别多比如大型 DTO 有几十个字段耗时线性增长但依然在可接受范围内。我现在的结论是反射方案最大的开销不在执行而在每次调用都重新反射字段元数据。只要用缓存把 Field[] 固定下来性能问题基本不存在。再配合“遇到第一个空字段立即返回”的策略绝大多数接口的耗时增加可以忽略不计。5. 从非空到更通用的字段校验边界在哪5.1 用自定义注解扩展字段规则反射非空判断只是反射在字段校验上的起点稍微扩展一下就能做成轻量级校验框架。比如定义一个Required注解标注在需要校验的字段上Target(ElementType.FIELD) Retention(RetentionPolicy.RUNTIME) public interface Required { String message() default 字段不能为空; }工具类里先判断字段上有没有这个注解有才校验非空if (field.isAnnotationPresent(Required.class)) { // 执行非空校验 }这样就能实现“同一个对象的某些字段必须校验、某些字段不校验”的灵活需求比“全部字段一刀切”更贴近真实业务。还可以继续扩展Length(min 2, max 20)、Pattern(regexp ...)等自定义注解配合反射遍历字段统一处理。这不就是一个小型 Bean Validation 吗对不想引入重量级框架的内部项目来说完全够用。不过别把它做成“什么都能干”的万能框架校验规则越复杂维护成本越高最后反而比标准方案还难收拾。5.2 反射校验与 Bean Validation 怎么选我实际工作中两种方案都长期用过体验下来边界很清楚。如果项目从零开始或者正在做 Spring Boot 新模块开发优先用 Bean Validation 的NotNull、NotEmpty、NotBlank配合Valid和全局异常处理器代码干净、语义清晰、IDE 也能给提示。这是长期最省心的路线。如果是老项目改造既有 DTO 数量巨大又不想给几百个字段逐个加注解反射工具类是最平滑的过渡方案。先写一个通用校验工具把核心非空规则统一管起来之后有需要再逐步迁移到注解校验也行。另外要清楚反射方案的短板它不太适合做国际化错误消息Bean Validation 有 MessageSource 支持反射方案得自己实现它也不太适合字段校验规则频繁变化的场景注解直观改起来快反射工具类每加一种规则都要改工具本身。还有如果接口入参需要跨层校验方法参数、嵌套对象、服务层Bean Validation 有现成的体系反射方案要自己处理嵌套递归成本会明显上升。最后再分享一个小经验无论是反射校验还是注解校验错误信息里一定要带字段名最好连当前值也带出来。我排查线上问题有相当高的比例就是靠“具体是哪个字段为空”这句话定位到入参的。如果只返回“参数校验失败”这种笼统提示调试起来真的会让人崩溃。