Zuo后端开发的兄弟们，咱们实话实说参数校验这事儿，真的是让人又爱又恨。爱的是它保障了系统的稳定性，恨的是那些写不完的判断逻辑。你有没有过这样的经历：一个接口参数十几个，你要在Service层或者Controller层写一堆 `if ` 或者 `if > 10)` 之类的代码？kan着那一坨坨像乱麻一样的 `if-else`，是不是感觉头皮发麻，代码洁癖瞬间发作？

以前我也一样，每次写业务逻辑前，dou得先过五关斩六将，把参数校验一遍。虽然Spring Boot自带的 `javax.validation` 配合 `@NotNull`、`@Size` 这些注解Neng解决一部分问题，但一旦遇到稍微复杂点的场景——比如“字段A的值取决于字段B”、“当开关打开时字段C不Neng为空”——这些原生注解就显得力不从心了。Zui后没办法，只Neng手写校验逻辑，或者自定义Validator，费时费力还容易出错。

忍无可忍之下我决定自己动手丰衣足食。经过一段时间的打磨，我研发了一款基于SpEL表达式的参数校验组件。这玩意儿到底有多强？这么说吧，它几乎Neng覆盖你所有Neng想象到的校验场景，而且代码简洁得让人想哭。今天我就把这个“神器”分享给大家，希望Neng帮各位从繁琐的校验逻辑中解脱出来。

🤔 为什么要造这个轮子？

咱们先来聊聊现状。在Java Web开发中，参数校验是必不可少的一环。Ru果不Zuo校验，轻则报错500，重则数据乱套。通常情况下大家会使用 `hibernate-validator` 提供的标准注解，比如：

`@NotNull`：不Neng为空。

`@Size`：长度或大小限制。

`@Pattern`：正则匹配。

这些对于简单的单体字段校验确实够用了。但是现实业务往往比这复杂得多。举个例子：

假设你有一个用户注册接口，其中包含“用户类型”和“用户ID”两个字段。业务要求：Ru果是“企业用户”，那么“用户ID”不Neng为空；Ru果是“个人用户”，则“用户ID”Ke以为空。这种条件依赖的校验，用标准注解就hen难直接实现了。

这时候，hen多同学就会选择在Controller里写 `if-else`：

if )) {
    if  == null) {
        throw new IllegalArgumentException;
    }
}

写一次还好，Ru果接口多了这种代码充斥在各个角落，维护起来简直是灾难。而且，这种业务逻辑混在校验代码里也不符合单一职责原则。

为了解决这个问题，我开发的这个 spel-validator 组件应运而生。它利用Spring强大的SpEL表达式语言，让你Ke以直接在注解里写校验逻辑，真正实现了“逻辑即配置”。

🚀 快速上手：三步搞定集成

别以为这东西有多难用，其实简单得令人发指。只要你用过Spring Boot，基本上kan一眼就Neng上手。

1. 引入Maven依赖

你得把我的jar包加入到你的项目中。目前Zui新版本Yi经发布到了Maven仓库，直接添加依赖即可：

    cn.sticki
    spel-validator
    1.0.0-beta 


    org.hibernate.validator
    hibernate-validator


    org.springframework.boot
    spring-boot-starter-web

注意，因为它是基于 `javax.validation` 的 ，所以你还是需要引入 `hibernate-validator` 和 `spring-boot-starter-web` 作为基础支撑。

2. 开启SpEL校验支持

这一步非常关键，特别是当你需要在表达式中调用Spring Bean的时候。你需要在启动类上加上一个注解：`@EnableSpelValidatorBeanRegistrar`。

@EnableSpelValidatorBeanRegistrar
@SpringBootApplication
public class Application {
    public static void main {
        SpringApplication.run;
    }
}

加上这个注解后校验器就Neng识别Spring容器里的Bean了这意味着你Ke以在校验表达式中直接注入Service来查库！是不是hen酷？

3. 在实体类上开搞

接下来就是见证奇迹的时刻。我们定义一个VO类，在类上使用 `@SpelValid` 注解，告诉框架：“嘿，这个类里的字段我要用SpEL表达式来校验，你帮我kan着点。”

@Data
@SpelValid
public class AudioParamVo {
    @NotNull
    private Boolean switchAudio;
    /**
     * 当 switchAudio 为 true 时audioContent 不Neng为null
     */
    @SpelNotNull
    private Object audioContent;
}

kan到 `@SpelNotNull` 里面的 `condition` 属性了吗？那就是SpEL表达式。`#this` 代表当前对象。这句话的意思就是：Ru果当前对象的 `switchAudio` 属性等于 `true`，那么 `audioContent` 就不Neng为空，否则报错。

然后在Controller里正常使用 `@Valid` 注解即可：

@RestController
@RequestMapping
public class ExampleController {
    @PostMapping
    public Resp simple {
        return Resp.ok;
    }
}

💡 核心玩法：那些原生注解Zuo不到的事

上面那个只是开胃菜，真正体现它“超强”的地方，在于处理那些复杂的、跨字段的、甚至需要调用外部服务的逻辑。

场景一：多字段联合校验

比如内容类型校验。Ru果 `contentType` 是1，代表音频，那 `audioContent` 就不Neng为空；Ru果是2，代表视频，那 `videoContent` 就不Neng为空。

@Data
@SpelValid
public class ContentParamVo {
    @NotNull
    private Integer contentType;
    @SpelNotNull
    private Object audioContent;
    @SpelNotNull
    private Object videoContent;
}

这种逻辑Ru果用 `if-else` 写，得写好几行，现在一个注解搞定，清晰明了。

场景二：调用静态方法Zuo复杂计算

有时候校验逻辑比较复杂，比如字符串长度计算，或者枚举值校验。这时候Ke以在SpEL中调用工具类的静态方法。

// 枚举值校验
@SpelAssert.getByCode != null", message = "用户状态不合法")
private Integer userStatus;
// 复杂长度校验：假设中文算2个字符，英文算1个，总长度不超过10
@SpelAssert.getLength <= 10", message = "用户名长度不Neng超过10")
private String userName;

这里用到了 `T` 语法，它用于引用类类型。`T` 就相当于拿到了类的Class对象，然后调用静态方法。这极大地 了校验的Neng力边界。

场景三：调用Spring Bean查库校验

这绝对是杀手锏级别的功Neng！想象一下你需要校验用户输入的 `userId` 在数据库里是否存在。以前你只Neng在Service里查库，现在你Ke以直接在注解里搞定。

@Data
@SpelValid
public class UserCheckVo {
    // 注意：这里只是演示，实际开发中为了性Neng，建议对高频查询Zuo缓存
    @SpelAssert != null", message = "用户不存在")
    private Long userId;
}

kan到 `@userService` 了吗？这就是Spring容器里的Bean名。只要你在启动类加了 `@EnableSpelValidatorBeanRegistrar`，校验器就会自动去Spring容器里找这个Bean并调用它的方法。这意味着你的校验逻辑Ke以直接访问数据库、Redis等任何资源！

🛠️ 进阶：自定义你的专属约束

虽然我内置了 `@SpelNotNull`、`@SpelAssert` 等注解，但肯定满足不了所有人的需求。好在我也支持你像原生 `javax.validation` 那样自定义约束注解。

步骤非常简单：

创建一个注解，加上 `@SpelConstraint`，指定你的校验器实现类。

加上 `message`、`groups`、`condition` 这三个固定属性。

实现校验逻辑。

比如我想Zuo一个专门校验“是否为偶数”的注解：

@SpelConstraint
@Retention
@Target
public @interface SpelEvenNumber {
    String message default "必须是偶数";
    Class groups default {};
    String condition default "true"; // 默认总是校验
}

然后实现验证器。这样你就拥有了一个属于自己的、可复用的校验注解。

⚠️ 全局异常处理与性Neng考量

校验不通过会抛出异常，为了给前端返回友好的提示，你需要配置一个全局异常处理器。这和标准的 `hibernate-validator` 处理方式是一模一样的。

@RestControllerAdvice
public class ControllerExceptionAdvice {
    @ExceptionHandler
    public Resp handleBindException {
        String msg = ex.getFieldErrors.stream
                .map + " " + error.getDefaultMessage)
                .reduce -> s1 + "," + s2)
                .orElse;
        return new Resp<>;
    }
}

关于性Neng，这可Neng是大家Zui关心的问题。毕竟SpEL表达式的解析和执行是有开销的，而且我的底层实现用到了反射。

这里我要坦诚地告诉大家：确实会有性Neng损耗。

但是这个损耗在绝大多数业务场景下是Ke以接受的。相比于网络IO、数据库查询，这点CPU计算时间简直微不足道。而且，我正在计划引入geng多的缓存机制，进一步降低开销。

我的建议是：Neng用原生 `javax.validation` 解决的简单场景，就别用 `spel-validator`。只有在遇到原生注解搞不定的复杂逻辑时再祭出这个大招。毕竟可维护性带来的长远收益，往往远大于那微不足道的性Neng损耗。

📝

这款工具的初衷，是为了解决我在实际项目中遇到的痛点。我不希望kan到大家把宝贵的开发时间浪费在写重复的、枯燥的校验代码上。通过 `spel-validator`，我们Ke以把校验逻辑收敛在注解中，让代码geng加整洁，让业务逻辑geng加纯粹。

目前项目Yi经在GitHub上开源，虽然还是Beta版本，但Yi经Ke以用于生产环境了。目前仅测试了JDK8环境，理论上JDK8+dou是支持的。

Ru果你在使用过程中遇到任何问题，或者有什么好的建议，欢迎去GitHub提Issue。对了关于IDEA对SpEL表达式的识别问题，目前我也在探索，Ru果你有好的解决方案，欢迎Pull Request！

Zui后别再让那些丑陋的 `if-else` 污染你的代码了试试这个工具，把时间花在geng有价值的业务逻辑上吧！GitHub地址就在文末，快去Star支持一下！

---