Java注解校验：如何用枚举/静态对象统一管理常量避冗余？

方案1：静态常量类分组管理 #

由于Java注解属性仅接受编译期常量（即static final修饰的基本类型/字符串，且赋值为字面量或其他常量表达式），可以把每个字段的校验参数拆分为单独的静态常量，按业务模块分组管理：

// 按业务模块定义常量类
public class UserFieldConstants {
    // 用户名字段的所有校验/序列化常量
    public static final String USER_NAME_JSON_KEY = "userName";
    public static final int USER_NAME_MAX_LENGTH = 150;
    public static final String USER_NAME_LENGTH_MSG = "用户名长度不能超过150字符";

    // 邮箱字段的所有校验/序列化常量
    public static final String EMAIL_JSON_KEY = "email";
    public static final int EMAIL_MAX_LENGTH = 200;
    public static final String EMAIL_LENGTH_MSG = "邮箱长度不能超过200字符";
}

在DTO中直接引用这些常量：

public class UserDTO {
    @Size(max = UserFieldConstants.USER_NAME_MAX_LENGTH, message = UserFieldConstants.USER_NAME_LENGTH_MSG)
    @JsonProperty(UserFieldConstants.USER_NAME_JSON_KEY)
    private String userName;

    @Size(max = UserFieldConstants.EMAIL_MAX_LENGTH, message = UserFieldConstants.EMAIL_LENGTH_MSG)
    @JsonProperty(UserFieldConstants.EMAIL_JSON_KEY)
    private String email;
}

• 优势：完全符合注解语法要求，常量集中管理，修改时只需改一处；
• 劣势：每个字段需定义多个常量，但比硬编码冗余度低很多。

方案2：自定义组合注解 #

把单个字段的@Size、@JsonProperty等注解封装成一个自定义注解，DTO中仅需添加这个组合注解即可：

// 针对用户名字段的组合注解
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Size(max = 150, message = "用户名长度不能超过150字符")
@JsonProperty("userName")
public @interface UserNameField {
}

在DTO中使用：

public class UserDTO {
    @UserNameField
    private String userName;
}

如果需要复用注解逻辑，可以借助Spring的@AliasFor实现属性传递，定义通用基础注解：

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Size
@JsonProperty
public @interface ValidatedField {
    @AliasFor(annotation = Size.class, attribute = "max")
    int maxLength() default 0;

    @AliasFor(annotation = Size.class, attribute = "message")
    String lengthMessage() default "";

    @AliasFor(annotation = JsonProperty.class, attribute = "value")
    String jsonKey() default "";
}

再定义具体字段的注解：

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@ValidatedField(maxLength = 150, lengthMessage = "用户名长度不能超过150字符", jsonKey = "userName")
public @interface UserNameField {
}

• 优势：DTO代码极度简洁，一个注解替代多个原生注解；
• 劣势：每个字段需创建一个自定义注解，适合字段规则固定且复用场景多的情况。

方案3：编译期代码生成（大规模字段场景） #

通过**注解处理器（Annotation Processor）**在编译期自动生成带有正确注解的DTO代码，核心思路是：

1. 定义包含所有字段规则的枚举或配置类；
2. 编写注解处理器读取配置，自动生成DTO类及字段上的注解（直接使用常量字面量）。

示例配置枚举：

public enum FieldRule {
    USER_NAME("userName", 150, "用户名长度不能超过150字符"),
    EMAIL("email", 200, "邮箱长度不能超过200字符");

    private final String jsonKey;
    private final int maxLength;
    private final String message;

    // 构造方法、getter省略
}

注解处理器会读取这个枚举，自动生成类似如下的DTO代码：

public class GeneratedUserDTO {
    @Size(max = 150, message = "用户名长度不能超过150字符")
    @JsonProperty("userName")
    private String userName;

    // 其他字段同理
}

• 优势：完全避免手动编写重复代码，规则集中在配置类，维护成本极低；
• 劣势：需要掌握注解处理器开发，有一定学习成本，适合数百个字段的大规模场景。

方案4：自定义全局校验器（替代注解校验） #

如果主要痛点是校验规则的集中管理，可以放弃@Size等原生校验注解，编写全局自定义校验器，读取枚举/配置类的规则进行校验：

1. 定义字段规则枚举（同方案3）；
2. 自定义校验注解和校验器：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = FieldRuleValidator.class)
public @interface ValidateByFieldRules {
}

public class FieldRuleValidator implements ConstraintValidator<ValidateByFieldRules, Object> {
    @Override
    public boolean isValid(Object dto, ConstraintValidatorContext context) {
        // 反射遍历DTO字段，匹配FieldRule中的规则
        // 例如：获取字段名，找到对应的FieldRule，检查字符串长度等
        // 不满足规则时，通过context添加校验错误信息
        return true;
    }
}

3. DTO上添加自定义校验注解，同时配合Jackson自定义命名策略实现@JsonProperty的效果：

@ValidateByFieldRules
public class UserDTO {
    private String userName;
    private String email;
}

• 优势：校验规则完全集中管理，无需在字段上加大量注解；
• 劣势：需要自己实现校验逻辑，反射可能带来轻微性能损耗，序列化/反序列化的字段名需额外处理。

内容的提问来源于stack exchange，提问作者Enzo Lopes