Spring MVC 通过 JSR 303/349 注解在服务端对表单数据做结构化校验，核心是将 @NotNull、@NotBlank、@Email、@Min/@Max、@Size、@Pattern 等约束直接标注于 DTO 字段，并配合 @Valid 与紧随其后的 BindingResult 在 Controller 中触发校验、捕获错误，确保业务逻辑仅在数据合法时执行，实现安全可控的数据入口防护。
Spring MVC 通过 JSR 303/349 规范的验证注解，在服务端对表单数据做结构化、可配置的校验，是保障输入安全的关键一环。它不依赖前端是否绕过、是否篡改，而是把校验逻辑固化在后端模型层和控制器入口处，真正守住数据进入业务逻辑前的最后一道关。
用标准注解定义字段规则
在接收表单数据的 DTO 或实体类字段上直接标注验证约束，让规则与数据模型绑定，清晰且可复用：
- @NotNull：防止空值（如必填用户名、邮箱）
- @NotBlank：比 @NotNull 更严格，还会校验字符串非空白（适合文本输入）
- @Email：自动检查邮箱格式（底层基于正则，无需手写 pattern）
- @Min/@Max：限制数值范围（例如年龄 0–150、评分 0–100）
- @Size(min = 2, max = 20)：控制字符串长度或集合元素个数
- @Pattern(regexp = "^1[3-9]\d{9}$")：自定义手机号等强格式要求
在 Controller 中触发并捕获校验结果
仅加注解不会自动生效，必须配合 @Valid（或 @Validated）启用校验，并用 BindingResult 接收错误信息：
- 将 @Valid 加在方法参数前（如
@Valid User user），Spring 会在绑定参数后立即执行校验 - BindingResult 必须紧跟在被校验参数之后，顺序不能错；它封装了所有校验失败的字段和 message
- 调用
result.hasErrors()判断是否校验失败，失败时应直接返回错误视图或统一响应体，绝不继续执行业务逻辑
统一返回友好且安全的错误提示
避免把技术细节（如字段名、内部异常）暴露给前端，推荐结构化返回：
立即学习“Java免费学习笔记（深入）”；
- 提取
BindingResult.getAllErrors()中的FieldError，取getDefaultMessage()（即注解里写的 message） - 组装成 JSON 响应，例如：
{"code":400,"message":"请求参数错误","errors":[{"field":"email","msg":"邮箱格式应有效"}]} - 不要在 message 中拼接用户输入内容（防 XSS），也不要返回堆栈或 Hibernate Validator 内部类名
补充增强安全性的重要实践
注解校验只是基础，还需搭配其他手段形成纵深防御：
- 确保项目已引入 hibernate-validator（JSR 实现）及对应版本兼容的依赖（如 Spring Boot 2.5+ 默认包含）
- 对敏感字段（密码、身份证号）额外做脱敏或加密处理，验证通过后也不应明文落库
- 结合 Spring Security 控制接口访问权限，避免未授权用户提交表单
- 对富文本、文件上传等特殊类型输入，仍需独立过滤（如 XSS 清洗、MIME 类型校验、大小限制）
