如何使用static修饰的断言工具类提升整个企业级项目数据校验的代码复用

静态断言工具类通过封装无状态校验逻辑为清晰命名的静态方法（如notNull、hasText），按语义分组、单一职责、统一异常格式，并与Spring/Lombok集成，在入口校验+全局异常处理实现标准化响应，支持安全扩展。

用 static 修饰的断言工具类，本质是把校验逻辑封装成无状态、可直接调用的静态方法，让全项目统一复用同一套校验规则，避免重复写 if (obj == null) 或 StringUtils.isEmpty() 这类代码。

定义清晰、聚焦单一职责的静态断言方法

不要堆砌所有校验逻辑到一个类里。按语义分组，比如 Assert.notNull() 检查非空，Assert.hasText() 检查非空白字符串，Assert.isTrue() 检查布尔表达式。每个方法只做一件事，参数明确（如字段名、错误提示），便于定位问题。

• 方法命名直白，如 Assert.notBlank(String str, String fieldName)
• 抛出运行时异常（如 IllegalArgumentException），不强制上层处理，符合断言语义
• 内部统一使用同一套错误消息格式，例如 "【%s】不能为空"，方便后期国际化或日志提取

配合 Lombok 或 Spring 的注解，在业务层自动触发校验

静态断言类不是孤立存在，要嵌入开发流程。比如在 Service 方法入口用它做快速守门：

• Spring Boot 中结合 @Valid + 自定义 ConstraintValidator，底层调用你的 static 断言方法
• Lombok 的 @NonNull 只生成空指针检查，不够灵活；可在 @RequiredArgsConstructor 构造后手动加 Assert.notNull(this.xxx)
• DTO 接收参数后，第一行就调用 Assert.notNull(request, "请求体")，失败即止，不往下执行无效逻辑

与统一异常处理器联动，实现错误响应标准化

所有静态断言抛出的异常，应在全局异常处理器中捕获并转为规范 JSON 响应（如 {"code": 400, "msg": "【用户名】不能为空"}）。这样前端不用关心 Java 异常类型，只解析固定字段。

• 定义一个基础校验异常类（如 ValidationException），所有 static 断言都抛这个
• 全局 @ControllerAdvice 拦截该异常，统一格式化返回
• 避免在各 Controller 里 try-catch，保持业务代码干净

支持扩展但不破坏原有契约

随着项目演进，可能需要新增校验场景（如手机号格式、身份证号合法性）。扩展方式必须兼容老调用：

• 新增方法用新名字（如 Assert.isMobile(String phone)），不修改已有方法签名
• 提供默认提示文案，也允许传入自定义 message，增强灵活性
• 必要时引入轻量级规则引擎（如简单正则 + 预置 pattern map），而非硬编码每种格式校验