1. 问题背景：@NotNull与@AssertTrue的冲突
在构建数据传输对象（DTO）时，我们经常会使用Bean Validation注解来确保数据的完整性和有效性。例如，@NotNull用于检查字段是否为空，而@AssertTrue则用于执行更复杂的业务逻辑验证。然而，当一个@AssertTrue注解的方法依赖于一个可能被@NotNull注解的字段时，可能会遇到意料之外的行为。
考虑以下DTO示例：
import lombok.Data;
import javax.validation.constraints.AssertTrue;
import javax.validation.constraints.NotNull;
@Data
public class Dto {
@NotNull
private Integer anInt;
@AssertTrue
public boolean isIntCustomValid() {
// 尝试访问 anInt
return anInt == 123 || anInt == 999;
}
}当anInt字段为null时，我们期望@NotNull能够捕获到这个错误。然而，实际情况是，isIntCustomValid()方法仍然会被调用。由于anInt此时为null，尝试对其进行比较操作（anInt == 123）会导致NullPointerException，并可能由Hibernate Validator（Bean Validation的常见实现）抛出HV000090: Unable to access的内部错误，而非预期的@NotNull验证失败信息。这使得验证流程变得不透明且难以调试。
2. 深入理解验证顺序与HV000090
Bean Validation规范本身并没有严格规定所有约束的执行顺序。通常，字段级别的约束（如@NotNull）和类/方法级别的约束（如@AssertTrue）可能会以某种顺序执行，或者在某些实现中，@AssertTrue方法在检查其依赖的字段是否为空之前就被调用。
HV000090: Unable to access错误通常发生在Hibernate Validator尝试访问一个属性或方法时，但由于某种原因（例如，依赖的字段为null导致方法内部逻辑抛出NullPointerException），访问失败。这表明@AssertTrue方法在@NotNull有机会报告anInt为null的错误之前，就已经因为anInt的null值而内部崩溃了。
虽然可以通过@GroupSequence和自定义验证组来强制验证顺序，但这通常需要创建额外的空接口作为标记，增加了代码的复杂性和冗余，对于这种简单的null依赖问题，通常被认为不是一种优雅的解决方案。
3. 解决方案：构建空值安全的@AssertTrue方法
解决此问题的关键在于，使@AssertTrue注解的方法能够容忍其依赖字段的null值，并将空值检查的职责完全交由@NotNull来处理。这意味着，当依赖字段为null时，@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，则返回 true。
// 这意味着此 @AssertTrue 约束在 anInt 为 null 时不进行判断，
// 将 null 检查的职责留给 @NotNull 注解。
return true;
}
}代码解析：
- Objects.nonNull(anInt)：这是一个安全的null检查，避免了直接访问anInt可能导致的NullPointerException。
- 当anInt不为null时，方法才执行原有的业务逻辑验证（anInt == 123 || anInt == 999）。
- 当anInt为null时，方法直接返回true。这一步至关重要，它告诉Bean Validation，对于anInt的null情况，isIntCustomValid方法是“通过”的，从而允许@NotNull约束继续发挥作用。此时，如果anInt确实是null，那么@NotNull约束将会被触发，并报告相应的错误信息，而不是HV000090。
4. 实践建议与注意事项
- Null-Safe设计： 在编写任何依赖于其他字段的@AssertTrue或自定义约束时，始终优先考虑被依赖字段的空值情况。确保你的验证逻辑在面对null值时不会抛出意外异常。
- 明确职责： 让@NotNull负责检查字段的空值，而@AssertTrue或自定义约束则专注于字段非空时的业务逻辑验证。通过这种方式，可以清晰地分离关注点。
- 错误信息： 为你的约束注解添加有意义的message属性，这有助于在验证失败时提供清晰的用户反馈。
- 避免过度设计： 除非确实需要复杂的验证顺序控制，否则应避免使用@GroupSequence等机制来解决简单的null依赖问题。本教程提供的方法通常更为简洁和直接。
5. 总结
通过在@AssertTrue方法内部引入简单的null检查，并根据检查结果返回适当的值，我们可以有效地解决@NotNull与@AssertTrue之间的潜在冲突，避免HV000090等内部错误，并确保Bean Validation以我们期望的方式工作。这种方法不仅代码简洁，而且提高了验证逻辑的健壮性和可读性。
