答案：Java参数校验应分层处理，DTO用@NotBlank、@Email等注解结合@Valid校验格式，Service层检查业务规则如唯一性，自定义@Phone等注解满足特殊需求，全局@ControllerAdvice捕获MethodArgumentNotValidException和BusinessException，统一返回结构化错误信息，提升系统稳定性和用户体验。
在Java开发中，验证用户输入的参数是保障系统稳定性和安全性的关键环节。合理的参数校验不仅能防止非法数据进入业务逻辑，还能提升用户体验。以下是参数校验与异常提示的最佳实践。
使用JSR-303/JSR-380（Bean Validation）进行注解校验
Java标准提供了基于注解的参数校验机制，常用的是 javax.validation 和 hibernate-validator 实现。
常见注解包括：
- @NotNull：不能为 null
- @NotBlank：字符串不能为空或空白
- @Size(min=2, max=10)：集合或字符串长度范围
- @Email：邮箱格式校验
- @Min / @Max：数值范围限制
- @Pattern：正则表达式匹配
示例：
立即学习“Java免费学习笔记（深入）”；
public class UserRequest {
@NotBlank(message = "用户名不能为空")
private String username;
@Email(message = "邮箱格式不正确")
private String email;
@Min(value = 18, message = "年龄不能小于18岁")
private Integer age;
}
在Controller中启用校验：
@PostMapping("/users")
public ResponseEntity<String> createUser(@Valid @RequestBody UserRequest request) {
// 业务逻辑
return ResponseEntity.ok("创建成功");
}
统一异常处理返回友好提示
当参数校验失败时，Spring会抛出 MethodArgumentNotValidException。通过全局异常处理器捕获并返回结构化错误信息。
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<Map<String, Object>> handleValidationExceptions(
MethodArgumentNotValidException ex) {
Map<String, Object> errors = new HashMap<>();
errors.put("status", 400);
errors.put("message", "参数校验失败");
List<String> errorList = ex.getBindingResult()
.getFieldErrors()
.stream()
.map(error -> error.getField() + ": " + error.getDefaultMessage())
.collect(Collectors.toList());
errors.put("errors", errorList);
return ResponseEntity.badRequest().body(errors);
}
}
这样前端收到的响应更清晰，例如：
{
"status": 400,
"message": "参数校验失败",
"errors": ["username: 用户名不能为空", "age: 年龄不能小于18岁"]
}
自定义校验注解应对复杂规则
对于通用性较强的特殊规则（如手机号、身份证号），可自定义校验注解。
步骤：
- 定义注解
- 实现 ConstraintValidator 接口
- 应用到字段
示例：自定义手机号校验
@Target({FIELD})
@Retention(RUNTIME)
@Constraint(validatedBy = PhoneValidator.class)
public @interface Phone {
String message() default "手机号格式不正确";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
public class PhoneValidator implements ConstraintValidator<Phone, String> {
private static final String PHONE_REGEX = "^1[3-9]\d{9}$";
@Override
public boolean isValid(String value, ConstraintValidatorContext context) {
if (value == null) return true; // 可为空由 @NotNull 控制
return value.matches(PHONE_REGEX);
}
}
使用：
@Phone(message = "请输入正确的手机号") private String phone;
服务层补充校验与业务规则检查
DTO校验仅解决格式问题，业务层面还需额外判断，例如：
- 用户是否已存在
- 账户余额是否充足
- 资源是否有权限访问
这类校验应在Service中进行，并抛出自定义业务异常：
if (userRepository.existsByUsername(request.getUsername())) {
throw new BusinessException("用户名已存在");
}
同样在全局异常处理器中捕获 BusinessException，返回统一格式。
基本上就这些。合理利用注解+全局异常处理，既能减少模板代码，又能保证前后端交互清晰。关键是把校验责任分层：DTO负责格式，Service负责业务逻辑，异常统一响应。不复杂但容易忽略细节。
