MyBatis 本身不参与参数校验，校验必须在 Controller 或 Service 层入参时由 Spring 的 validation 完成；需显式引入 spring-boot-starter-validation 依赖，校验应作用于 DTO 类而非实体类或 @Param 单值。
在 Spring Boot 中，MyBatis 本身不参与参数校验——它只负责 SQL 执行。所谓“在 MyBatis 前校验”，实际是指在请求到达 Mapper 接口或 SQL 执行之前，由 Spring 的校验机制完成拦截和验证，确保非法参数根本不会进入 MyBatis 流程。核心思路是：校验发生在 Controller 层或 Service 层入参处，而非 MyBatis 层。
必须引入校验依赖
Spring Boot 2.3+ 版本起，spring-boot-starter-validation 不再默认包含在 web starter 中，需显式添加：
- Maven 中补全依赖：
<dependency><br> <groupId>org.springframework.boot</groupId><br> <artifactId>spring-boot-starter-validation</artifactId><br></dependency>
- Gradle 对应写法：
implementation 'org.springframework.boot:spring-boot-starter-validation'
校验要落在 DTO 或入参对象上，而不是实体类
避免直接在校验 MyBatis 的 @Param 单值或 @Mapper 接口方法参数上使用注解（无效）。正确做法是：
- 定义专用的 DTO 类（如
UserRegisterDTO），字段标注@NotBlank、@Email、@Pattern等 - Controller 方法用
@Valid或@Validated标记该 DTO - 校验失败会自动触发
MethodArgumentNotValidException，不会走到 MyBatis 的insert()或update()
示例：public ResponseEntity> register(@Valid @RequestBody UserRegisterDTO dto)
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
单个参数或 @Param 场景怎么校验？
若接口确实只传一个 String、Long 等基础类型（比如 @PathVariable Long id 或 @RequestParam String code），可直接在参数前加校验注解，但需配合类级 @Validated：
@RestController<br>@Validated<br>public class UserController {<br> @GetMapping("/user/{id}")<br> public User getById(@PathVariable @Min(1) Long id) { ... }<br>}- 注意：
@PathVariable和@RequestParam支持@Min、@NotNull、@Pattern等，但不支持@Valid（因非对象）
避免 MyBatis 入参绕过校验的常见坑
以下写法会导致校验失效，务必规避：
- ❌ 在 Mapper 接口方法上直接对
@Param("name") String name加@NotBlank—— 注解不生效 - ❌ 把 MyBatis 实体类（如
UserDO）直接当 Controller 入参并加@Valid—— 若该类含数据库自增字段（如id、createTime），校验逻辑易与业务语义冲突 - ❌ 在 Service 方法参数上加
@Valid却未在 Controller 调用时传递有效对象 —— 校验链断裂，MyBatis 仍可能执行
可靠做法始终是：校验入口统一收束在 Controller 层，且面向明确的 DTO。
