问题描述：@NotNull与@AssertTrue的默认行为冲突
在使用Java Bean Validation（JSR 380）进行数据校验时，开发者常常会结合使用多个注解来确保数据的完整性和业务逻辑正确性。@NotNull用于检查字段是否为null，而@AssertTrue则允许定义一个返回布尔值的自定义方法，以实现更复杂的验证逻辑。
然而，一个常见的问题是，当一个字段同时被@NotNull修饰，并且有一个@AssertTrue方法依赖于该字段的值时，即使@NotNull验证失败（即字段为null），@AssertTrue方法仍可能被执行。这会导致在@AssertTrue方法中尝试访问一个空值字段时，抛出NullPointerException，进而被Hibernate Validator捕服为HV000090: Unable to access property/method错误。
例如，考虑以下DTO结构：
import lombok.Data;
import javax.validation.constraints.AssertTrue;
import javax.validation.constraints.NotNull;
@Data
public class Dto {
@NotNull(message = "anInt 不能为空")
private Integer anInt;
@AssertTrue(message = "anInt 必须是123或999")
public boolean isIntCustomValid() {
// 当anInt为null时，这里会抛出NullPointerException
return anInt == 123 || anInt == 999;
}
}在控制器中，如果使用@Valid注解触发验证：
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;
import javax.validation.Valid;
@RestController
public class MyController {
@PostMapping("/validate")
public String validateDto(@Valid @RequestBody Dto dto) {
return "DTO 验证成功";
}
}当请求体中anInt字段为null时，期望的结果是只触发@NotNull的验证失败，并返回相应的错误信息。但实际情况是，isIntCustomValid()方法也会被调用，并因anInt为null而抛出异常，最终导致HV000090错误。
解决方案：在@AssertTrue方法中增加空值检查
解决此问题的最直接和优雅的方法是，在@AssertTrue修饰的自定义验证方法内部，显式地对所依赖的字段进行空值检查。只有当字段非空时，才执行其核心的业务逻辑验证。如果字段为空，则直接返回true，表示在这种情况下（字段已由@NotNull处理），此自定义验证条件被视为通过。
修改后的DTO如下：
import lombok.Data;
import javax.validation.constraints.AssertTrue;
import javax.validation.constraints.NotNull;
import java.util.Objects; // 导入Objects工具类
@Data
public class Dto {
@NotNull(message = "anInt 不能为空")
private Integer anInt;
@AssertTrue(message = "anInt 必须是123或999")
public boolean isIntCustomValid() {
// 优先检查anInt是否为null
if (Objects.nonNull(anInt)) {
// 只有当anInt不为null时，才执行具体的业务逻辑验证
return anInt == 123 || anInt == 999;
}
// 如果anInt为null，则认为此AssertTrue条件通过。
// 因为anInt的null性已由@NotNull注解负责处理。
return true;
}
}工作原理：
- 当anInt为null时，isIntCustomValid()方法被调用。
- Objects.nonNull(anInt)判断为false。
- 方法直接返回true。这意味着@AssertTrue的验证逻辑在anInt为null时不会抛出异常，并且被认为是“通过”的。
- 此时，@NotNull注解会捕获anInt为null的情况，并报告相应的验证错误。
- 当anInt不为null时，Objects.nonNull(anInt)判断为true。
- 方法继续执行anInt == 123 || anInt == 999的逻辑，根据结果返回true或false。
通过这种方式，我们有效地将@AssertTrue的执行逻辑“绑定”到anInt非空的前提下，避免了因访问空引用而导致的HV000090错误，同时保持了验证的清晰性：@NotNull负责非空检查，@AssertTrue负责非空情况下的业务逻辑检查。
替代方案与比较
原问题中提到尝试使用@GroupSequence和@Groups。虽然这确实是处理复杂验证顺序的一种标准且强大的机制，但对于本例这种简单的“如果字段非空则执行自定义验证”的场景，它可能显得过于复杂。
使用@GroupSequence的步骤通常包括：
- 定义空接口作为验证组（例如FirstValidationGroup.class, SecondValidationGroup.class）。
- 在@NotNull和@AssertTrue上分别指定不同的验证组。
- 在DTO或方法参数上使用@GroupSequence指定验证组的执行顺序。
例如：
public interface FirstValidation {}
public interface SecondValidation {}
@Data
@GroupSequence({FirstValidation.class, SecondValidation.class, Dto.class}) // Dto.class代表默认组
public class Dto {
@NotNull(groups = FirstValidation.class)
private Integer anInt;
@AssertTrue(groups = SecondValidation.class)
public boolean isIntCustomValid() {
return anInt == 123 || anInt == 999;
}
}这种方法确实能控制验证顺序，但引入了额外的接口和更复杂的配置。对于本例，仅仅是为了避免一个NullPointerException，在@AssertTrue方法内部进行空值检查更为简洁和直观，因为它将相关的逻辑封装在了一起，减少了样板代码。只有当验证逻辑的依赖关系非常复杂，或者需要根据不同场景应用不同的验证规则集时，@GroupSequence才更具优势。
注意事项
- 防御性编程： 在任何自定义验证方法中，如果该方法依赖于DTO的某个字段，始终建议进行空值检查，以避免不必要的运行时错误。这是一种良好的编程实践。
- 错误消息： 确保@NotNull和@AssertTrue都提供了清晰的错误消息，以便前端或调用方能够准确理解验证失败的原因。
- 验证粒度： 这种解决方案将@AssertTrue的有效性绑定到了其依赖字段的非空性上。如果业务需求是即使字段为null，@AssertTrue也应该表达某种“无效”状态，那么就需要重新审视验证逻辑，或者确实考虑使用@GroupSequence来强制分离验证阶段。但在大多数情况下，如果一个自定义验证依赖于字段的值，那么字段为null时，该自定义验证通常不应被视为失败，而是由@NotNull负责处理。
总结
在Spring Boot中使用Bean Validation时，@NotNull与@AssertTrue的组合验证顺序问题是一个常见痛点。通过在@AssertTrue修饰的自定义验证方法中添加简单的空值检查，我们可以优雅地解决HV000090错误，确保验证逻辑在正确的前提下执行，同时避免引入复杂的验证组配置。这种方法简洁、高效，且易于理解和维护，是处理此类场景的推荐实践。
