今年年初我接了一个订单批量导入的需求上游给的 CSV 一次就是几万行字段二十几个要求入库前逐行校验错误要精确到“第几行、哪个字段、什么原因”逐条返回给业务方。这个模块本身不算复杂但真正动手时我发现自己用了很多年的 Apache Commons Validator 在这种场景里越用越别扭。正好团队里有人提到 ValidX一个主打链式 API 和类型安全的轻量校验库于是我把两个库拉到同一个项目里做了两周的功能与性能对比。这篇文章就是那段时间的完整记录包含代码写法、实测数据、踩坑过程以及我最终怎么做的取舍。如果你也在做类似的选型或者正被复杂的参数校验折磨这篇应该能帮你省下不少时间。1. 对比起因一个订单导入模块把我逼到了选择路口1.1 原先的“验证工具”习惯Apache Commons Validator 是 Apache Commons 家族里的老牌项目我在之前的项目里一直拿它做表单校验和参数校验用法基本都是 EmailValidator.getInstance().isValid(email)、UrlValidator、CreditCardValidator 这类静态方法调用。好处是稳定规则都是经过大量项目验证的异常 case 处理得比较全。坏处也很明显它只接受 String 输入而且校验逻辑要靠调用方手动组织。在过去几年里我基本上是把 Commons Validator 当“规则字典”用的——遇到邮箱就调 EmailValidator遇到 URL 就调 UrlValidator遇到日期就调 DateValidator。应付普通的表单提交场景完全够用。但一旦校验逻辑复杂起来代码就会变得很长错误信息还得自己拼维护成本一点一点往上涨。1.2 新需求带来的三个具体问题这次订单导入模块有三个方面让 Commons Validator 显得力不从心第一个问题是字段类型。CSV 读进来虽然是字符串但业务字段本质上是什么是 BigDecimal、LocalDate、枚举。Commons Validator 全部按 String 处理导致我每次都要先做类型转换再调校验或者先校验完再转类型来回倒腾代码里全是 try-catch。第二个问题是错误信息。Commons Validator 的 isValid 只返回 boolean我需要自己拼错误信息。“第 328 行收货金额超出限额”这种信息只能靠自己在外面包一层逻辑而且拼出来的格式还不统一。第三个问题是嵌套结构。订单里有明细行明细行里又有商品、地址等子对象还要对集合里的每个元素逐个校验。Commons Validator 对嵌套天然不支持我得手动遍历、层层调用代码又长又容易漏。这几个痛点凑到一起促使我去找替代方案。ValidX 就是在这时候进入视野的。关于 ValidX可能不少读者还比较陌生简单来说它是一个相对新的 Java 校验库核心思路是把校验规则声明成可复用的规则链支持对任意 Java 类型做校验不再局限于 String。以下所有关于 ValidX 的描述都基于我测试时使用的 2.1.x 版本不同版本的行为可能会有差异。2. 两套设计思路规则字典与链式校验2.1 Apache Commons Validator以“预置规则类”为核心的成熟派Commons Validator 的设计思想很朴素把常见校验规则封装成独立的类每个类负责一种规则。EmailValidator 管邮箱、UrlValidator 管 URL、CreditCardValidator 管信用卡号、DateValidator 管日期格式、RegexValidator 提供通用正则能力。EmailValidator emailValidator EmailValidator.getInstance(); boolean ok emailValidator.isValid(someoneexample.com);这种设计的好处是简单直接。规则类经过大量项目验证边界 case 处理得比较全EmailValidator 甚至能区分 RFC 严格模式和非严格模式。对大多数写业务代码的人来说不需要理解它内部的正则表达式直接调用就是。但它的设计局限也很明显一切输入都是字符串。这源自它诞生的时代。2002 年前后的 Java Web 应用表单提交的数据天然都是 StringServlet 拿到的请求参数也是 String那时候面向字符串做校验是合理的也是唯一的选择。可二十多年后的今天我们的数据来源已经从“表单字符串”变成了“JSON 对象”“DTO”“领域模型”字符串中心的校验思路就逐渐跟不上趟了。2.2 ValidX把校验当作数据流处理的现代派ValidX 的设计思路完全不一样。它把待校验对象看作一条数据流通过一组声明式的约束条件依次对数据做判断最终输出一个包含全部错误的结果对象。核心 API 是链式的ValidationResult result ValidX.validate(user) .field(email, User::getEmail) .notBlank(邮箱不能为空) .email(邮箱格式不正确) .field(age, User::getAge) .notNull(年龄不能为空) .range(18, 65, 年龄必须在18到65之间) .check();这中间有几个关键差异值得展开说。第一类型化输入。User::getEmail 返回 StringUser::getAge 返回 Integer校验器能拿到真实类型不再需要字符串中转。CSV 里的字符串在进入校验之前先被转换成了业务类型校验器只负责对类型化数据做判断职责清晰。第二错误信息内建在规则里。每条规则都可以带自定义消息消息模板里还能引用字段名、当前值、阈值等收集错误时按字段路径聚类返回。这一点对我的导入模块直接命中要害。第三规则可以复用。我可以把“收货地址校验”定义成一个独立的 AddressRule 规则对象然后在订单校验和用户资料校验里同时引用规则只写一遍处处生效。2.3 两者对“输入”这件事的根本分歧这两个库的分歧本质是校验的输入到底是什么。Commons Validator 认为输入是“字符串形式的表单字段”所以它的 API 全部围绕 String 设计。这在传统 MVC 表单提交场景里足够用也符合它的历史定位。ValidX 认为输入是“任意 Java 对象的字段”字符串只是其中一种类型。这更贴近现代微服务、DTO 校验、批处理导入这类场景。这个分歧直接决定了后面所有功能对比和性能差异。所以我在对比时没有简单地说谁好谁坏而是先明确自己的主要场景订单导入模块里 80% 的字段是金额、日期、枚举、嵌套对象纯字符串格式校验只占小头。带着这个判断再去对比优先级就清晰多了。3. 功能对比预置规则、扩展方式、错误收集与国际化3.1 预置规则覆盖范围对照我先把实测中整理的两边预置规则对照表列出来规则类型Apache Commons ValidatorValidX邮箱EmailValidator支持RFC严格/宽松模式email()基于预编译正则支持可选域名校验URLUrlValidator可配置协议白名单url()默认检查 http/https信用卡CreditCardValidator支持Luhn算法无内置需自定义规则ISBNISBNValidator无内置需自定义日期DateValidator基于SimpleDateFormatdate()基于DateTimeFormatter支持模式字符串数字区间无内置需用RegexValidator或自写range()支持 Comparable 泛型边界字符串长度无内置需用 RegexValidatorlength()IP地址InetAddressValidatorIPv4/IPv6ipv4() / ipv6()null/空值无统一处理靠调用方判断notNull()/notBlank()/notEmpty()正则RegexValidatormatches()嵌套对象不支持需手动遍历支持规则链可嵌套集合元素校验不支持支持对 List/Set 逐元素校验这张表不是想证明谁覆盖得更全而是想说明两者的侧重点完全不同。Commons Validator 在“格式化字符串规则”上积累很深信用卡、ISBN 这类细分规则它都有ValidX 则把力气花在“通用 Java 类型和组合校验”上格式类规则只保留了最常用的几种。3.2 自定义规则的写法对比自定义规则是实际项目里最常做的事。Commons Validator 的做法是继承抽象类或实现接口把校验逻辑写在一个类里public class OrderAmountValidator extends AbstractValidator { Override public boolean isValid(Object value) { if (!(value instanceof String)) { return false; } BigDecimal amount new BigDecimal((String) value); return amount.compareTo(BigDecimal.valueOf(100000)) 0; } }然后手动调用boolean ok new OrderAmountValidator().isValid(amountStr);ValidX 的写法是把自定义规则包装成一个泛型 Rule 对象或者在链式调用里直接传 PredicateRuleBigDecimal amountLimit Rule.of( order.amount.limit, amount - amount.compareTo(BigDecimal.valueOf(100000)) 0, 单笔金额不能超过10万 ); ValidationResult result ValidX.validate(order) .field(amount, Order::getAmount) .add(amountLimit) .check();两种方式都能实现自定义规则但维护成本差别很大。Commons Validator 的自定义类一般只能处理 String如果想校验 BigDecimal外面还得先做类型转换ValidX 的 Rule 是泛型的规则本身就绑定到 BigDecimal 类型类型转换发生在规则外部规则内部不需要关心“这个值是从 CSV 来的还是从 JSON 来的”。3.3 嵌套校验、集合校验与错误聚合这是我在订单导入场景里最看重的一块。嵌套结构在真实业务里太常见了public class Order { private String orderNo; private ListOrderLine lines; private Address shipAddress; }Commons Validator 面对这种结构基本无能为力只能自己在业务代码里写循环for (OrderLine line : order.getLines()) { if (line.getQuantity() null || line.getQuantity() 0) { errors.add(行号 index 数量必须大于0); } }这段代码本身不复杂问题在于它散落在业务代码里无法复用也无法统一管理错误消息格式。ValidX 的嵌套规则可以把子对象的校验声明为 Rule再挂到父级规则链上RuleOrderLine lineRule ValidX.rules(OrderLine.class) .field(quantity, OrderLine::getQuantity) .notNull(数量不能为空) .min(1, 数量必须大于0) .build(); ValidationResult result ValidX.validate(order) .field(lines, Order::getLines) .forEach(lineRule) .field(shipAddress, Order::getShipAddress) .apply(addressRule) .check();错误聚合方面差异更明显。Commons Validator 的 isValid 只返回 boolean错误详情需要自己收集ValidX 返回的 ValidationResult 会按字段路径组织错误消息比如 lines[2].quantity 数量必须大于0。我拿到以后可以直接拼到导入失败报表里不用再做二次加工。3.4 线程安全、依赖体积与框架集成线程安全这块我必须强调选型时最容易忽略。Commons Validator 官方文档建议把 Validator 实例作为单例使用它的预置类内部做了线程安全处理。我实测多个线程同时调用 EmailValidator.getInstance().isValid 没有出现共享状态问题这是它作为老牌库的可靠性体现。ValidX 的规则对象和校验器本身设计为无状态所以也是线程安全的。但这里有个使用方责任如果在自定义 Rule 里不小心写了可变成员变量就会出现竞态问题。这个锅不能甩给库是使用姿势不对。依赖体积方面我对比了两个 jar 的大小。Commons Validator 1.7 加上它依赖的 commons-lang3加在一起大概是 500KB 出头ValidX 2.1.x 核心包不到 200KB没有外部依赖。在微服务镜像瘦身的场景里这个差距还是值得留意的。当然体积不是决定性因素但如果你对交付物体积敏感这是个加分项。框架集成上Commons Validator 有对应的 Struts 插件在老的 Web 框架里地位很高。ValidX 更偏向与 Spring Boot 的 DTO 场景配合它本身不硬绑 Spring但提供了和 Jakarta Validation 注解兼容的适配层可以把 NotNull、Size 这类注解转换成它的规则。4. 性能实测三个贴近生产的基准场景功能对比做完以后我开始跑性能测试。性能测试最容易犯的错是测“玩具场景”比如只测一次邮箱校验的耗时那毫无意义。我这次刻意设计了三个贴近生产使用的场景并且处理了 JIT 预热影响。4.1 测试环境与方法JDKOpenJDK 17.0.9基准框架JMH 1.37机器MacBook Pro M1 Pro16GB 内存每次基准跑 5 轮每轮 3 秒预热加 5 秒测量取最优轮结果校验库版本Commons Validator 1.7ValidX 2.1.x数据从真实订单样本里随机抽取保证通过率和失败率都不是 0%4.2 场景一单字段热路径校验第一个场景是最高频的单字段校验拿 1 万个样本邮箱对比 EmailValidator.isValid 和 ValidX 的 email() 规则。场景Commons Validator 1.7ValidX 2.1.x合法邮箱校验约 480 ns/次约 350 ns/次非法邮箱校验约 520 ns/次约 360 ns/次IP 地址校验约 220 ns/次约 240 ns/次邮箱校验上 ValidX 略快大概有 20% 到 30% 的差距。原因是 Commons Validator 的 EmailValidator 内部实现比较复杂要处理 RFC 822 里的各种边缘情况正则本身也更长ValidX 的 email() 用的是更简化的正则匹配路径更短。但 IP 校验上两者几乎持平Commons Validator 甚至略快。这说明“谁快”和具体规则强相关不能一概而论。4.3 场景二多规则链式组合校验第二个场景模拟真实 DTO 校验一个用户对象包含邮箱、年龄、昵称长度、手机号格式四条规则全部通过才算成功。场景Commons Validator 1.7ValidX 2.1.x四条规则组合全部通过约 1.9 μs/次约 1.4 μs/次四条规则组合其中一条失败约 1.5 μs/次约 1.1 μs/次这个场景 ValidX 的优势更明显。原因有两个一是 ValidX 的规则链在构建时就编译成了一次性执行的结构避免了多次方法调用开销二是 Commons Validator 在这个组合场景里需要我手工串起四个不同的 Validator 类中间涉及 String 常量创建和临时对象这部分开销在 JMH 里会被计入。4.4 场景三嵌套对象与集合批量校验第三个场景是订单导入的真实路径一个订单包含 5 条明细和 1 个地址对 1000 个订单做批量校验。场景Commons Validator 1.7 手写循环ValidX 2.1.x1000 个订单每个含 5 条明细 1 地址约 18.2 ms约 9.7 msCommons Validator 在这个场景里慢不是它本身的校验逻辑慢而是因为我必须用业务代码做嵌套遍历、错误收集、类型转换这些代码产生的临时对象和逻辑开销全被算进去了。这引出一个很重要的结论在复杂业务场景里库的 API 设计对性能的影响往往比校验算法本身更大。ValidX 把嵌套遍历和错误聚合内建在框架里省掉的其实是使用者手写的那层胶水代码。4.5 性能数据的正确打开方式我要提醒一句上面这些数字只代表我这台机器、这个 JDK、这两个版本下的结果不代表所有环境都这样。M1 Pro 上的 JDK17 和公司服务器的 x86 JDK11 跑出来可能是另一组数。真正值得关注的是相对差距和趋势单条简单规则大家差不多规则组合和嵌套场景下 ValidX 因为少了一层胶水代码而更有优势。也不要为了性能数据去选库。我见过有人为了某个基准测试快 10% 就换框架结果后续开发效率被 API 的别扭程度拖累。性能应该作为选型的一个因素而不是唯一因素。5. 选型路上容易踩的坑我的排查笔记两周的对比测试里我踩了不少坑。这里挑几个最典型的记录下来帮后面的人少走弯路。5.1 邮箱校验规则不同导致的“假阳性”第一个坑是邮箱校验规则不一致。Commons Validator 的 EmailValidator 默认允许 namelocalhost 这类没有顶级域名的地址而 ValidX 的 email() 默认要求域名里带点。测试的时候我发现同一批数据两个库给出的“合法/非法”判断不一样排查了半天才发现是规则定义差异不是 bug。解法很简单明确业务规则。如果业务上只接受公网邮箱就用 ValidX 的严格模式或者在 Commons Validator 里加 TLD 白名单。关键是不能想当然地以为“邮箱校验”在哪个库里行为都一样。5.2 null 与空串两边策略不一致的隐患第二个坑是 null 和空串的处理策略。Commons Validator 里 EmailValidator.isValid(null) 返回 falseisValid() 也返回 false但 ValidX 的 email() 默认把 null 视为“未提供”不会触发格式校验只有显式调用 notNull() 才会拦截。这个差异在字段可选时可要命一个可选邮箱字段用户没填Commons Validator 会判非法ValidX 会放过。这不是谁对谁错而是“格式校验”和“必填校验”被拆成了两件事。Commons Validator 把它们混在一起ValidX 把它们拆开。选型的时候一定要搞清楚你们团队的心智模型否则会出现“本地跑得好好的上线后一堆校验失败”的翻车现场。5.3 正则表达式预编译与过度封装第三个坑和性能有关。Commons Validator 的 RegexValidator 构造时会把正则编译好这一点做得不错。但我发现有人为了图省事在每次请求里 new RegexValidator(...)等于每次都重新编译一遍正则性能直接掉一个数量级。这不是库的问题是使用姿势的问题。ValidX 这边也有类似的坑。它的 Rule 对象构建本身有开销如果我在循环体里反复构建同一个规则JMH 测出来会明显变慢。正确做法是把规则对象声明成 static final 或者用单例构建一次反复使用。5.4 不要把性能对比当唯一依据第四个坑是我在复盘时意识到的。一开始我盯着性能数字差点选了一个性能更好但用起来更别扭的方案。后来冷静下来把两个库在真实业务场景里各写了一版完整实现才发现性能差距在整体耗时里占比很小代码可维护性、团队熟悉度、错误信息管理才是大头。这也是我写这篇文章的初衷对比不是为了分个高下而是搞清楚每个库在什么场景下最合适。6. 我的最终选择与使用心得两周对比下来我的选择是订单导入模块用 ValidX老系统的存量表单校验继续保留 Commons Validator。这个选择不是“谁取代谁”而是各自放在合适的位置。订单导入模块的字段类型复杂、嵌套结构多、错误信息要求精确到行ValidX 的类型化规则链和错误聚合能力直接解决了我最痛的三个问题。老系统里那些基于 Struts 的表单页面动它们的成本远高于收益Commons Validator 继续用没有毛病。以下是我在实际使用 ValidX 过程中的一些体会第一规则复用是它最大的隐藏价值。我把“收货地址校验”“订单行校验”抽成独立 Rule 后导入模块和接口层校验共用同一套规则再也不会出现“导入时能过、接口调用时被拦”的不一致。第二错误消息模板要尽早规范化。ValidX 支持在消息里带字段名和当前值我建议团队从一开始就统一消息格式比如“字段[orderNo]: 不能为空”否则后期改格式要动的地方非常多。第三如果你们项目已经在用 Jakarta Validation 的 Valid 注解那套ValidX 的适配层可以让你平滑迁移但不要两种注解混用。混用会导致校验逻辑分散在两套体系里排查问题的时候非常痛苦。最后再分享一个小技巧无论选哪个库都建议在项目里加一个统一的校验入口把“校验规则定义”和“校验调用方式”隔离。这样即使某天想换库改动也只集中在一个地方而不是散落在所有业务代码里。好的校验框架能帮你省时间但好的封装习惯能让你随时换框架都不慌。
Java参数校验库选型：Commons Validator与ValidX实战对比
今年年初我接了一个订单批量导入的需求上游给的 CSV 一次就是几万行字段二十几个要求入库前逐行校验错误要精确到“第几行、哪个字段、什么原因”逐条返回给业务方。这个模块本身不算复杂但真正动手时我发现自己用了很多年的 Apache Commons Validator 在这种场景里越用越别扭。正好团队里有人提到 ValidX一个主打链式 API 和类型安全的轻量校验库于是我把两个库拉到同一个项目里做了两周的功能与性能对比。这篇文章就是那段时间的完整记录包含代码写法、实测数据、踩坑过程以及我最终怎么做的取舍。如果你也在做类似的选型或者正被复杂的参数校验折磨这篇应该能帮你省下不少时间。1. 对比起因一个订单导入模块把我逼到了选择路口1.1 原先的“验证工具”习惯Apache Commons Validator 是 Apache Commons 家族里的老牌项目我在之前的项目里一直拿它做表单校验和参数校验用法基本都是 EmailValidator.getInstance().isValid(email)、UrlValidator、CreditCardValidator 这类静态方法调用。好处是稳定规则都是经过大量项目验证的异常 case 处理得比较全。坏处也很明显它只接受 String 输入而且校验逻辑要靠调用方手动组织。在过去几年里我基本上是把 Commons Validator 当“规则字典”用的——遇到邮箱就调 EmailValidator遇到 URL 就调 UrlValidator遇到日期就调 DateValidator。应付普通的表单提交场景完全够用。但一旦校验逻辑复杂起来代码就会变得很长错误信息还得自己拼维护成本一点一点往上涨。1.2 新需求带来的三个具体问题这次订单导入模块有三个方面让 Commons Validator 显得力不从心第一个问题是字段类型。CSV 读进来虽然是字符串但业务字段本质上是什么是 BigDecimal、LocalDate、枚举。Commons Validator 全部按 String 处理导致我每次都要先做类型转换再调校验或者先校验完再转类型来回倒腾代码里全是 try-catch。第二个问题是错误信息。Commons Validator 的 isValid 只返回 boolean我需要自己拼错误信息。“第 328 行收货金额超出限额”这种信息只能靠自己在外面包一层逻辑而且拼出来的格式还不统一。第三个问题是嵌套结构。订单里有明细行明细行里又有商品、地址等子对象还要对集合里的每个元素逐个校验。Commons Validator 对嵌套天然不支持我得手动遍历、层层调用代码又长又容易漏。这几个痛点凑到一起促使我去找替代方案。ValidX 就是在这时候进入视野的。关于 ValidX可能不少读者还比较陌生简单来说它是一个相对新的 Java 校验库核心思路是把校验规则声明成可复用的规则链支持对任意 Java 类型做校验不再局限于 String。以下所有关于 ValidX 的描述都基于我测试时使用的 2.1.x 版本不同版本的行为可能会有差异。2. 两套设计思路规则字典与链式校验2.1 Apache Commons Validator以“预置规则类”为核心的成熟派Commons Validator 的设计思想很朴素把常见校验规则封装成独立的类每个类负责一种规则。EmailValidator 管邮箱、UrlValidator 管 URL、CreditCardValidator 管信用卡号、DateValidator 管日期格式、RegexValidator 提供通用正则能力。EmailValidator emailValidator EmailValidator.getInstance(); boolean ok emailValidator.isValid(someoneexample.com);这种设计的好处是简单直接。规则类经过大量项目验证边界 case 处理得比较全EmailValidator 甚至能区分 RFC 严格模式和非严格模式。对大多数写业务代码的人来说不需要理解它内部的正则表达式直接调用就是。但它的设计局限也很明显一切输入都是字符串。这源自它诞生的时代。2002 年前后的 Java Web 应用表单提交的数据天然都是 StringServlet 拿到的请求参数也是 String那时候面向字符串做校验是合理的也是唯一的选择。可二十多年后的今天我们的数据来源已经从“表单字符串”变成了“JSON 对象”“DTO”“领域模型”字符串中心的校验思路就逐渐跟不上趟了。2.2 ValidX把校验当作数据流处理的现代派ValidX 的设计思路完全不一样。它把待校验对象看作一条数据流通过一组声明式的约束条件依次对数据做判断最终输出一个包含全部错误的结果对象。核心 API 是链式的ValidationResult result ValidX.validate(user) .field(email, User::getEmail) .notBlank(邮箱不能为空) .email(邮箱格式不正确) .field(age, User::getAge) .notNull(年龄不能为空) .range(18, 65, 年龄必须在18到65之间) .check();这中间有几个关键差异值得展开说。第一类型化输入。User::getEmail 返回 StringUser::getAge 返回 Integer校验器能拿到真实类型不再需要字符串中转。CSV 里的字符串在进入校验之前先被转换成了业务类型校验器只负责对类型化数据做判断职责清晰。第二错误信息内建在规则里。每条规则都可以带自定义消息消息模板里还能引用字段名、当前值、阈值等收集错误时按字段路径聚类返回。这一点对我的导入模块直接命中要害。第三规则可以复用。我可以把“收货地址校验”定义成一个独立的 AddressRule 规则对象然后在订单校验和用户资料校验里同时引用规则只写一遍处处生效。2.3 两者对“输入”这件事的根本分歧这两个库的分歧本质是校验的输入到底是什么。Commons Validator 认为输入是“字符串形式的表单字段”所以它的 API 全部围绕 String 设计。这在传统 MVC 表单提交场景里足够用也符合它的历史定位。ValidX 认为输入是“任意 Java 对象的字段”字符串只是其中一种类型。这更贴近现代微服务、DTO 校验、批处理导入这类场景。这个分歧直接决定了后面所有功能对比和性能差异。所以我在对比时没有简单地说谁好谁坏而是先明确自己的主要场景订单导入模块里 80% 的字段是金额、日期、枚举、嵌套对象纯字符串格式校验只占小头。带着这个判断再去对比优先级就清晰多了。3. 功能对比预置规则、扩展方式、错误收集与国际化3.1 预置规则覆盖范围对照我先把实测中整理的两边预置规则对照表列出来规则类型Apache Commons ValidatorValidX邮箱EmailValidator支持RFC严格/宽松模式email()基于预编译正则支持可选域名校验URLUrlValidator可配置协议白名单url()默认检查 http/https信用卡CreditCardValidator支持Luhn算法无内置需自定义规则ISBNISBNValidator无内置需自定义日期DateValidator基于SimpleDateFormatdate()基于DateTimeFormatter支持模式字符串数字区间无内置需用RegexValidator或自写range()支持 Comparable 泛型边界字符串长度无内置需用 RegexValidatorlength()IP地址InetAddressValidatorIPv4/IPv6ipv4() / ipv6()null/空值无统一处理靠调用方判断notNull()/notBlank()/notEmpty()正则RegexValidatormatches()嵌套对象不支持需手动遍历支持规则链可嵌套集合元素校验不支持支持对 List/Set 逐元素校验这张表不是想证明谁覆盖得更全而是想说明两者的侧重点完全不同。Commons Validator 在“格式化字符串规则”上积累很深信用卡、ISBN 这类细分规则它都有ValidX 则把力气花在“通用 Java 类型和组合校验”上格式类规则只保留了最常用的几种。3.2 自定义规则的写法对比自定义规则是实际项目里最常做的事。Commons Validator 的做法是继承抽象类或实现接口把校验逻辑写在一个类里public class OrderAmountValidator extends AbstractValidator { Override public boolean isValid(Object value) { if (!(value instanceof String)) { return false; } BigDecimal amount new BigDecimal((String) value); return amount.compareTo(BigDecimal.valueOf(100000)) 0; } }然后手动调用boolean ok new OrderAmountValidator().isValid(amountStr);ValidX 的写法是把自定义规则包装成一个泛型 Rule 对象或者在链式调用里直接传 PredicateRuleBigDecimal amountLimit Rule.of( order.amount.limit, amount - amount.compareTo(BigDecimal.valueOf(100000)) 0, 单笔金额不能超过10万 ); ValidationResult result ValidX.validate(order) .field(amount, Order::getAmount) .add(amountLimit) .check();两种方式都能实现自定义规则但维护成本差别很大。Commons Validator 的自定义类一般只能处理 String如果想校验 BigDecimal外面还得先做类型转换ValidX 的 Rule 是泛型的规则本身就绑定到 BigDecimal 类型类型转换发生在规则外部规则内部不需要关心“这个值是从 CSV 来的还是从 JSON 来的”。3.3 嵌套校验、集合校验与错误聚合这是我在订单导入场景里最看重的一块。嵌套结构在真实业务里太常见了public class Order { private String orderNo; private ListOrderLine lines; private Address shipAddress; }Commons Validator 面对这种结构基本无能为力只能自己在业务代码里写循环for (OrderLine line : order.getLines()) { if (line.getQuantity() null || line.getQuantity() 0) { errors.add(行号 index 数量必须大于0); } }这段代码本身不复杂问题在于它散落在业务代码里无法复用也无法统一管理错误消息格式。ValidX 的嵌套规则可以把子对象的校验声明为 Rule再挂到父级规则链上RuleOrderLine lineRule ValidX.rules(OrderLine.class) .field(quantity, OrderLine::getQuantity) .notNull(数量不能为空) .min(1, 数量必须大于0) .build(); ValidationResult result ValidX.validate(order) .field(lines, Order::getLines) .forEach(lineRule) .field(shipAddress, Order::getShipAddress) .apply(addressRule) .check();错误聚合方面差异更明显。Commons Validator 的 isValid 只返回 boolean错误详情需要自己收集ValidX 返回的 ValidationResult 会按字段路径组织错误消息比如 lines[2].quantity 数量必须大于0。我拿到以后可以直接拼到导入失败报表里不用再做二次加工。3.4 线程安全、依赖体积与框架集成线程安全这块我必须强调选型时最容易忽略。Commons Validator 官方文档建议把 Validator 实例作为单例使用它的预置类内部做了线程安全处理。我实测多个线程同时调用 EmailValidator.getInstance().isValid 没有出现共享状态问题这是它作为老牌库的可靠性体现。ValidX 的规则对象和校验器本身设计为无状态所以也是线程安全的。但这里有个使用方责任如果在自定义 Rule 里不小心写了可变成员变量就会出现竞态问题。这个锅不能甩给库是使用姿势不对。依赖体积方面我对比了两个 jar 的大小。Commons Validator 1.7 加上它依赖的 commons-lang3加在一起大概是 500KB 出头ValidX 2.1.x 核心包不到 200KB没有外部依赖。在微服务镜像瘦身的场景里这个差距还是值得留意的。当然体积不是决定性因素但如果你对交付物体积敏感这是个加分项。框架集成上Commons Validator 有对应的 Struts 插件在老的 Web 框架里地位很高。ValidX 更偏向与 Spring Boot 的 DTO 场景配合它本身不硬绑 Spring但提供了和 Jakarta Validation 注解兼容的适配层可以把 NotNull、Size 这类注解转换成它的规则。4. 性能实测三个贴近生产的基准场景功能对比做完以后我开始跑性能测试。性能测试最容易犯的错是测“玩具场景”比如只测一次邮箱校验的耗时那毫无意义。我这次刻意设计了三个贴近生产使用的场景并且处理了 JIT 预热影响。4.1 测试环境与方法JDKOpenJDK 17.0.9基准框架JMH 1.37机器MacBook Pro M1 Pro16GB 内存每次基准跑 5 轮每轮 3 秒预热加 5 秒测量取最优轮结果校验库版本Commons Validator 1.7ValidX 2.1.x数据从真实订单样本里随机抽取保证通过率和失败率都不是 0%4.2 场景一单字段热路径校验第一个场景是最高频的单字段校验拿 1 万个样本邮箱对比 EmailValidator.isValid 和 ValidX 的 email() 规则。场景Commons Validator 1.7ValidX 2.1.x合法邮箱校验约 480 ns/次约 350 ns/次非法邮箱校验约 520 ns/次约 360 ns/次IP 地址校验约 220 ns/次约 240 ns/次邮箱校验上 ValidX 略快大概有 20% 到 30% 的差距。原因是 Commons Validator 的 EmailValidator 内部实现比较复杂要处理 RFC 822 里的各种边缘情况正则本身也更长ValidX 的 email() 用的是更简化的正则匹配路径更短。但 IP 校验上两者几乎持平Commons Validator 甚至略快。这说明“谁快”和具体规则强相关不能一概而论。4.3 场景二多规则链式组合校验第二个场景模拟真实 DTO 校验一个用户对象包含邮箱、年龄、昵称长度、手机号格式四条规则全部通过才算成功。场景Commons Validator 1.7ValidX 2.1.x四条规则组合全部通过约 1.9 μs/次约 1.4 μs/次四条规则组合其中一条失败约 1.5 μs/次约 1.1 μs/次这个场景 ValidX 的优势更明显。原因有两个一是 ValidX 的规则链在构建时就编译成了一次性执行的结构避免了多次方法调用开销二是 Commons Validator 在这个组合场景里需要我手工串起四个不同的 Validator 类中间涉及 String 常量创建和临时对象这部分开销在 JMH 里会被计入。4.4 场景三嵌套对象与集合批量校验第三个场景是订单导入的真实路径一个订单包含 5 条明细和 1 个地址对 1000 个订单做批量校验。场景Commons Validator 1.7 手写循环ValidX 2.1.x1000 个订单每个含 5 条明细 1 地址约 18.2 ms约 9.7 msCommons Validator 在这个场景里慢不是它本身的校验逻辑慢而是因为我必须用业务代码做嵌套遍历、错误收集、类型转换这些代码产生的临时对象和逻辑开销全被算进去了。这引出一个很重要的结论在复杂业务场景里库的 API 设计对性能的影响往往比校验算法本身更大。ValidX 把嵌套遍历和错误聚合内建在框架里省掉的其实是使用者手写的那层胶水代码。4.5 性能数据的正确打开方式我要提醒一句上面这些数字只代表我这台机器、这个 JDK、这两个版本下的结果不代表所有环境都这样。M1 Pro 上的 JDK17 和公司服务器的 x86 JDK11 跑出来可能是另一组数。真正值得关注的是相对差距和趋势单条简单规则大家差不多规则组合和嵌套场景下 ValidX 因为少了一层胶水代码而更有优势。也不要为了性能数据去选库。我见过有人为了某个基准测试快 10% 就换框架结果后续开发效率被 API 的别扭程度拖累。性能应该作为选型的一个因素而不是唯一因素。5. 选型路上容易踩的坑我的排查笔记两周的对比测试里我踩了不少坑。这里挑几个最典型的记录下来帮后面的人少走弯路。5.1 邮箱校验规则不同导致的“假阳性”第一个坑是邮箱校验规则不一致。Commons Validator 的 EmailValidator 默认允许 namelocalhost 这类没有顶级域名的地址而 ValidX 的 email() 默认要求域名里带点。测试的时候我发现同一批数据两个库给出的“合法/非法”判断不一样排查了半天才发现是规则定义差异不是 bug。解法很简单明确业务规则。如果业务上只接受公网邮箱就用 ValidX 的严格模式或者在 Commons Validator 里加 TLD 白名单。关键是不能想当然地以为“邮箱校验”在哪个库里行为都一样。5.2 null 与空串两边策略不一致的隐患第二个坑是 null 和空串的处理策略。Commons Validator 里 EmailValidator.isValid(null) 返回 falseisValid() 也返回 false但 ValidX 的 email() 默认把 null 视为“未提供”不会触发格式校验只有显式调用 notNull() 才会拦截。这个差异在字段可选时可要命一个可选邮箱字段用户没填Commons Validator 会判非法ValidX 会放过。这不是谁对谁错而是“格式校验”和“必填校验”被拆成了两件事。Commons Validator 把它们混在一起ValidX 把它们拆开。选型的时候一定要搞清楚你们团队的心智模型否则会出现“本地跑得好好的上线后一堆校验失败”的翻车现场。5.3 正则表达式预编译与过度封装第三个坑和性能有关。Commons Validator 的 RegexValidator 构造时会把正则编译好这一点做得不错。但我发现有人为了图省事在每次请求里 new RegexValidator(...)等于每次都重新编译一遍正则性能直接掉一个数量级。这不是库的问题是使用姿势的问题。ValidX 这边也有类似的坑。它的 Rule 对象构建本身有开销如果我在循环体里反复构建同一个规则JMH 测出来会明显变慢。正确做法是把规则对象声明成 static final 或者用单例构建一次反复使用。5.4 不要把性能对比当唯一依据第四个坑是我在复盘时意识到的。一开始我盯着性能数字差点选了一个性能更好但用起来更别扭的方案。后来冷静下来把两个库在真实业务场景里各写了一版完整实现才发现性能差距在整体耗时里占比很小代码可维护性、团队熟悉度、错误信息管理才是大头。这也是我写这篇文章的初衷对比不是为了分个高下而是搞清楚每个库在什么场景下最合适。6. 我的最终选择与使用心得两周对比下来我的选择是订单导入模块用 ValidX老系统的存量表单校验继续保留 Commons Validator。这个选择不是“谁取代谁”而是各自放在合适的位置。订单导入模块的字段类型复杂、嵌套结构多、错误信息要求精确到行ValidX 的类型化规则链和错误聚合能力直接解决了我最痛的三个问题。老系统里那些基于 Struts 的表单页面动它们的成本远高于收益Commons Validator 继续用没有毛病。以下是我在实际使用 ValidX 过程中的一些体会第一规则复用是它最大的隐藏价值。我把“收货地址校验”“订单行校验”抽成独立 Rule 后导入模块和接口层校验共用同一套规则再也不会出现“导入时能过、接口调用时被拦”的不一致。第二错误消息模板要尽早规范化。ValidX 支持在消息里带字段名和当前值我建议团队从一开始就统一消息格式比如“字段[orderNo]: 不能为空”否则后期改格式要动的地方非常多。第三如果你们项目已经在用 Jakarta Validation 的 Valid 注解那套ValidX 的适配层可以让你平滑迁移但不要两种注解混用。混用会导致校验逻辑分散在两套体系里排查问题的时候非常痛苦。最后再分享一个小技巧无论选哪个库都建议在项目里加一个统一的校验入口把“校验规则定义”和“校验调用方式”隔离。这样即使某天想换库改动也只集中在一个地方而不是散落在所有业务代码里。好的校验框架能帮你省时间但好的封装习惯能让你随时换框架都不慌。
