Spring Boot参数校验需分层实施：Controller层用@Validated/@Valid+基础注解做入口格式校验；Service层结合注解与手动check保障业务规则；全局异常统一处理返回结构化错误；按需扩展自定义注解与分组校验。

Spring Boot 中参数校验不是“加几个注解就完事”，而是要分层、有重点、可维护。核心在于用对位置、选对注解、配好兜底，避免重复判空或漏校验。

Controller 层：守好入口，做格式与基础规则校验

这是第一道防线，目标是快速拦截明显非法请求，比如空字段、超长字符串、错误邮箱格式等。不在此处拦住，脏数据就可能一路穿透到数据库。

• 在 Controller 类上加 @Validated（启用类级校验）
• 对 @RequestBody 对象用 @Valid；对单个路径/查询参数（如 @PathVariable、@RequestParam）直接加校验注解（@NotBlank、@Min 等）
• DTO 字段推荐组合使用：@NotBlank（非空非空白）、@Size(min=2, max=20)（长度）、@Email 或 @Pattern（格式）

Service 层：守住业务逻辑，校验规则与状态合法性

Controller 层只管“像不像”，Service 层要管“能不能”。即使有人绕过 Web 层直接调用 Service（如内部测试、RPC 调用），也必须保证参数合规。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 在 Service 接口或实现类上标注 @Validated
• 方法参数同样用 @Valid（对象）或基础注解（简单类型）
• 校验内容应升级：例如“注册时用户名是否已存在”“转账金额不能为负”“操作时间不能早于创建时间”——这些无法靠注解自动完成，需在方法体内手动 check，但校验入口仍统一由 @Validated 触发

全局异常统一处理：不让校验失败暴露堆栈

别让每个 Controller 都写 BindingResult 判断。用 @RestControllerAdvice 拦截标准校验异常，返回结构化错误响应。

• 捕获 MethodArgumentNotValidException（@Valid 报错）和 ConstraintViolationException（@Validated 单参数报错）
• 提取字段名、错误信息、错误码，组装成统一 JSON 格式（如 {"code":400,"field":"email","message":"邮箱格式不正确"}）
• 这样前端能精准提示哪个输入框出错，后端无冗余代码

进阶建议：按需扩展，不堆砌

大多数项目不需要自定义注解，但遇到高频复用规则时值得封装：

• 手机号、身份证号、银行卡号等，适合写 @Phone、@IdCard 注解，复用率高、语义清晰
• 分组校验（@Validated({Create.class})）适合多步骤表单，如“新增时不校验 ID，更新时必须传 ID”
• 嵌套对象校验只需在 DTO 的字段上加 @Valid，框架会递归校验内部属性
• 避免过度校验：数据库已有唯一索引的字段，Service 层不必再查一遍是否存在；校验逻辑尽量前置，别等入库失败才抛异常