spring boot参数校验性能开销极小，万级qps下耗时增加通常低于0.02ms；性能瓶颈多源于校验方式不当、异常处理冗余或粒度失控。
Spring Boot 的参数校验本身性能开销极小，几乎可忽略——它只是在反序列化后、进入 Controller 方法前，对 JavaBean 字段做一次反射读取 + 注解规则判断，不涉及 IO、不触发数据库、也不创建大量对象。实测表明，在万级 QPS 场景下，启用 @Valid 校验带来的平均耗时增加通常低于 0.02ms。真正影响性能的，往往不是校验动作本身，而是校验方式不当、异常处理冗余或校验粒度失控。
校验逻辑别进业务层
避免在 Service 或 DAO 层重复校验已由 Controller 层验证过的参数。例如：
- Controller 已用
@Valid @RequestBody UserDTO校验了邮箱格式、密码强度等，Service 就不该再调用StringUtils.isBlank(user.getEmail())或手写正则二次判断； - 若需在多个地方复用同一套规则，应把 DTO 和校验注解作为契约统一维护，而非把校验逻辑“复制粘贴”到各层；
- 特别注意：不要在循环体中对每个元素都 new Validator 实例或手动调用
validator.validate()—— Spring 的@Valid是框架托管、懒加载、单例复用的，效率远高于手动校验。
异常处理要轻量且精准
默认的校验失败会抛出 MethodArgumentNotValidException（@RequestBody）或 BindException（@ModelAttribute），这些异常携带完整 BindingResult，含全部字段错误信息。但如果你只返回简单 JSON 错误码，却让全局异常处理器把整个 BindingResult 对象转成字符串再解析，就白白浪费了 CPU 和内存。
- 全局异常处理器中，直接从异常里提取
bindingResult.getAllErrors()，遍历拿到FieldError的getDefaultMessage()即可，无需 toString() 或日志全量打印； - 禁用堆栈跟踪（
logger.error("参数校验失败", e)→ 改为logger.warn("参数校验失败: {}", e.getMessage())），避免生成和序列化巨量 stack trace； - 生产环境关闭
spring.mvc.throw-exception-if-no-handler-found=true类似配置，防止 404 也被误捕获进校验异常链。
复杂规则尽量提前拦截
像手机号、身份证、银行卡号这类校验，正则表达式本身很快，但若写成 @Pattern(regexp = "...", message = "...")，每次都要编译 Pattern（虽然有缓存），且无法复用业务逻辑中的预处理（如去空格、补前缀）。更高效的做法是：
- 自定义注解 +
ConstraintValidator，在校验器中先value = value.trim().replace(" ", "")，再走标准校验流程； - 对高频调用的规则（如短信验证码校验），考虑用 Guava 的
CacheLoader缓存校验结果（按 code+phone 组合 key），5 分钟内相同请求直接返回缓存值； - 前端提交前加简单 JS 校验（非安全依赖），能过滤掉 90% 明显非法输入，减少无效请求打到后端。
嵌套校验注意深度和范围
@Valid 支持级联校验，但每多一层嵌套，就多一次反射 + 遍历字段 + 创建子校验上下文。若 DTO 包含 List
- 只对真正需要校验的字段加
@Valid，避免无脑标注整个 List； - 用分组校验（
@Validated({Create.class})）隔离不同接口场景，比如新增接口校验全部字段，编辑接口只校验不可为空字段； - 对超大集合（如上传 1000 条订单明细），改用异步批量校验 + 分页提交，而不是一股脑塞进一个
@RequestBody。
