Java Bean Validation：@NotNull与@AssertTrue执行顺序解析

1. Bean Validation中@NotNull与@AssertTrue的协同挑战

在Java Bean Validation（JSR 380）中，我们经常使用注解来定义数据模型的约束。@NotNull用于确保字段值非空，而@AssertTrue则用于方法级别，定义更复杂的业务逻辑校验。一个常见的场景是，一个字段既需要非空，又需要满足特定的业务规则：

@Data
public class Dto {

    @NotNull(message = "anInt 不能为空")
    private Integer anInt;

    @AssertTrue(message = "anInt 必须是 123 或 999")
    public boolean isIntCustomValid() {
        // 尝试访问 anInt 字段
        return anInt == 123 || anInt == 999;
    }
}

当使用@Valid注解触发校验时，例如在一个Spring MVC控制器中：

@RestController
public class MyController {

    @PostMapping("/validate")
    public String validateDto(@Valid @RequestBody Dto dto) {
        return "Validation successful!";
    }
}

此时，如果客户端提交的JSON数据中anInt字段为null，我们期望@NotNull能够捕获到这个错误。然而，在某些情况下，@AssertTrue注解的isIntCustomValid()方法可能会在anInt为null时被执行，导致NullPointerException，或者更具体地，由于Hibernate Validator尝试访问一个空值而抛出HV000090: Unable to access错误。

这通常是因为Bean Validation的默认校验流程不保证字段级别的@NotNull约束总是在方法级别的@AssertTrue之前执行，特别是在@AssertTrue方法内部直接引用了可能为空的字段时。当@AssertTrue方法被调用时，它会尝试解引用anInt，如果anInt为null，就会导致运行时错误。

2. 解决方案：构建空值安全的@AssertTrue断言

解决此问题的最直接和优雅的方法是，在@AssertTrue注解的方法内部添加对关联字段的空值检查。这样，即使anInt为null，方法也能安全地执行，并将空值情况的处理权交回给@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 不为空，则执行业务逻辑校验
            return anInt == 123 || anInt == 999;
        }
        // 如果 anInt 为空，则此 @AssertTrue 约束视为通过。
        // 空值校验的责任将完全由 @NotNull 承担。
        return true;
    }
}

工作原理分析：

• 当anInt为null时，Objects.nonNull(anInt)返回false，isIntCustomValid()方法直接返回true。这意味着对于@AssertTrue而言，当anInt为null时，这个特定的业务规则被认为是满足的。
• 此时，@NotNull约束会正常发挥作用，捕获到anInt为null的错误，并生成相应的校验消息。
• 当anInt不为null时，Objects.nonNull(anInt)返回true，isIntCustomValid()方法会执行其核心业务逻辑（anInt == 123 || anInt == 999），确保只有满足条件的anInt值才能通过校验。

这种方法避免了NullPointerException或HV000090错误，并且清晰地分离了@NotNull和@AssertTrue的职责：@NotNull负责判断是否为空，而@AssertTrue负责在非空情况下判断业务逻辑。

3. GroupSequence与空值安全断言的对比

在Bean Validation中，@GroupSequence和@Groups提供了一种更严格的验证组排序机制，可以确保某些验证组（例如包含@NotNull的组）在其他组（例如包含@AssertTrue的组）之前执行。例如：

// 定义空接口作为验证组
public interface FirstValidationGroup {}
public interface SecondValidationGroup {}

@Data
@GroupSequence({FirstValidationGroup.class, SecondValidationGroup.class, Dto.class})
public class Dto {

    @NotNull(message = "anInt 不能为空", groups = FirstValidationGroup.class)
    private Integer anInt;

    @AssertTrue(message = "anInt 必须是 123 或 999", groups = SecondValidationGroup.class)
    public boolean isIntCustomValid() {
        // 注意：这里不再需要 Objects.nonNull 检查，因为我们依赖组顺序
        return anInt == 123 || anInt == 999;
    }
}

并在控制器中指定验证组：

@PostMapping("/validate")
public String validateDto(@Validated({FirstValidationGroup.class, SecondValidationGroup.class}) @RequestBody Dto dto) {
    return "Validation successful!";
}

这种方法确实能够保证@NotNull先于@AssertTrue执行，如果@NotNull失败，则后续的@AssertTrue不会被执行。然而，它引入了额外的复杂性：

• 需要创建空的标记接口：每当需要明确的验证顺序时，都可能需要定义新的接口。
• 增加代码量和概念负担：管理多个验证组和它们的顺序会使代码更难理解和维护。
• 适用场景有限：@GroupSequence主要用于需要严格分阶段验证的复杂场景，例如表单提交的不同步骤。

相比之下，在@AssertTrue内部进行空值检查的方案更为简洁，对于单个字段的空值与业务逻辑组合校验的场景，它提供了更低的实现成本和更高的可读性。它将空值安全逻辑内聚在约束方法内部，避免了全局验证顺序的复杂配置。

4. 注意事项与最佳实践

1. 选择合适的方案：

   • 对于字段级别的@NotNull与方法级别的@AssertTrue结合校验，且@AssertTrue方法依赖该字段的场景，推荐使用空值安全断言方案（即在@AssertTrue方法内添加Objects.nonNull()检查）。这种方案简单、直观，且易于维护。
   • 只有当你的业务逻辑确实需要严格的验证阶段划分（例如，第一步验证基本数据格式，第二步验证业务规则），并且这些阶段之间存在依赖关系时，才考虑使用@GroupSequence。

2. 清晰的错误消息：确保@NotNull和@AssertTrue都提供了清晰、用户友好的错误消息，以便在校验失败时能准确地告知问题所在。

3. 理解校验生命周期：虽然我们通过空值检查解决了特定问题，但深入理解Bean Validation的校验生命周期和不同类型约束的执行时机，有助于更好地设计和调试复杂的校验逻辑。

总结

在Java Bean Validation中，当@NotNull与@AssertTrue同时应用于一个DTO，并且@AssertTrue方法依赖于被@NotNull约束的字段时，为了避免运行时错误，最优雅的解决方案是在@AssertTrue方法内部增加空值检查。通过Objects.nonNull()判断，我们可以确保方法在安全的环境下执行业务逻辑，同时将字段的空值校验职责明确地留给@NotNull。这种方法比使用@GroupSequence更为简洁，更适用于此类特定场景，提升了代码的健壮性和可维护性。