批量数据校验需用@Validated+嵌套@Valid实现集合感知与错误归因；手动遍历+BindingResult可精准定位索引级错误；唯一性校验须前置查库分批比对；动态规则应结合Easy Rules或Drools，并从配置中心加载阈值。
批量数据的参数校验不能简单套用单条数据的 @Valid 注解，否则会校验失效或抛出不明确异常。核心思路是：**让校验逻辑感知“集合”，并把每条子项的错误精准归因到具体位置**。
用 @Validated + 嵌套集合校验
Spring Boot 默认不支持直接对 List<DTO> 参数做级联校验，需显式启用：
- DTO 类字段上加
@Valid（如List<@Valid UserDTO> users） - Controller 方法参数加
@Validated，而非仅@Valid - 确保 DTO 内部字段已标注
@NotBlank、@Min等注解
这样 Spring 会对每个 UserDTO 实例独立执行 JSR-303 校验，并聚合全部错误返回。
手动遍历 + BindingResult 收集错误
当需要更细粒度控制（比如记录第几条数据出错、跳过非法项继续处理），推荐手动校验：
- 注入
ValidatorBean - 循环调用
validator.validate(dto) - 将
Set<ConstraintViolation<T>>转为带索引的错误列表，例如：
{"index": 2, "field": "email", "message": "邮箱格式不正确"}
这种方式便于前端高亮错误行，也利于日志追踪和补偿处理。
数据库唯一性等业务规则需前置查库
像“用户名不能重复”“订单号+商品ID组合唯一”这类校验，注解无法完成，必须主动查库比对：
- 提取所有待校验字段值（如全部
username列表） - 用
WHERE username IN (:usernames)一次查询已有记录 - 对比找出重复项，构造结构化错误反馈（含原始索引）
- 大数据量时务必分批（如每 500 条一批），避免 SQL 参数超长或内存溢出
结合规则引擎应对动态复杂场景
若校验逻辑频繁变化（如风控规则、运营配置），硬编码或注解维护成本高：
- 5~8 条稳定规则 → 用 Easy Rules，基于 POJO 和注解定义
- 10+ 条可配置规则 → Drools + Excel 决策表，支持运营后台修改
- 所有规则阈值（如“单日下单上限=5”）应从 Nacos/Apollo 加载，不写死在代码里
关键点是：预编译规则容器、分片执行、错误结果统一包装为 ValidationError 对象，含 dataId、ruleCode、message。
