“又要写判空了。”
这句话在我维护老项目的日子里，出现频率比“好的”都高。每个新接口过来，第一件事就是把入参对象从头到尾捋一遍，然后为每个字段写一段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 List<OrderItem> 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() == 0； - Map 为 null 或
isEmpty()； - 数组为 null 或
length == 0； - 基本类型不参与判空，因为 int、long 等都有默认值 0，不存在“空”的说法。真需要区分“没传”和“传了 0”，那就用包装类型加 null 判断。
这个分类一定要在工具类里一网打尽，否则就会出现在同一个对象上规则不一致的情况。我的做法是写一个isBlankValue方法，内部用instanceof区分各种类型，最后兜底判断 null。
2.2 反射拿字段：getDeclaredFields 与 getFields
Java 反射里有俩特别容易混的 API：Class.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 Map<Class<?>, 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) { List<Field> 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_CACHE，key 是 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 时非 null，isBlankValue也不会命中。如果业务上“0 也是无效值”，这个工具类不适用，要么在调用方单独处理，要么给字段换成包装类型。
3.2 在业务中怎么调用
使用非常简单，一行代码搞定：
String nullField = FieldCheckUtil.getFirstNullField(request); if (nullField != null) { return Result.fail("参数校验失败，字段 " + nullField + " 不能为空"); }如果你希望一次把所有空字段都收集起来，可以再加一个getAllNullFields方法，返回List<String>或者Map<String, 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.lang=ALL-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[]，一次性 setAccessible |
4.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 有现成的体系，反射方案要自己处理嵌套递归，成本会明显上升。
最后再分享一个小经验：无论是反射校验还是注解校验，错误信息里一定要带字段名，最好连当前值也带出来。我排查线上问题，有相当高的比例就是靠“具体是哪个字段为空”这句话定位到入参的。如果只返回“参数校验失败”这种笼统提示，调试起来真的会让人崩溃。
