构造代码块不适用于DTO映射与校验，因其无法感知字段来源、介入赋值逻辑或联动Spring Validation；应采用分层协作方案：Lombok+注解校验+Controller声明式校验，或MapStruct/Service层显式校验，复杂逻辑用自定义约束注解。
构造代码块本身不适用于 DTO 的变量映射与校验——它在对象实例化时执行，但无法感知字段来源、无法介入属性赋值逻辑，更不能配合 Spring Validation 或 MapStruct 等主流机制完成“映射+校验”闭环。真正实用的方案是分层协作：用构造器/Record 初始化数据，用注解驱动校验，用映射工具处理来源转换。
别用构造代码块做校验
构造代码块（即 { ... } 块）在每次 new 实例时无条件执行，但它：
- 看不到是谁给字段赋的值（是 JSON 反序列化？是 MapStruct 赋值？还是手动 set？）
- 无法抛出符合 Spring MVC 规范的
MethodArgumentNotValidException，前端收不到标准错误格式 - 无法与
@NotBlank、@Valid等注解联动，校验规则散落各处，难维护 - 若 DTO 含嵌套对象（如
List<ItemDto>），构造块无法递归触发子对象校验
推荐组合：Lombok + Validation 注解 + Controller 层声明式校验
这是最轻量、最可控、也最符合 Spring 生态的做法：
- DTO 类用
@Data（或record）快速定义结构 - 关键字段直接加
@NotBlank、@NotNull、@Min(1)等约束 - 嵌套对象字段标注
@Valid，触发级联校验 - Controller 方法参数加
@Valid @RequestBody，由 Spring 自动拦截并返回 400 错误
示例：
public record OrderCreateDto(
@NotBlank(message = "订单号不能为空") String orderNo,
@NotNull(message = "商品数量不能为 null") Integer quantity,
@Valid List<ItemDto> items
) {}
public record ItemDto(
@NotBlank String sku,
@Min(1) BigDecimal price
) {}
调用时只要参数不合法，Spring 就自动返回标准错误体，无需手写一行校验代码。
当 DTO 来源不是 JSON，而是其他对象（如 Entity）时
此时校验应发生在映射之后、业务处理之前，推荐两种方式：
-
MapStruct + 自定义验证方法：在
@Mapper接口中定义一个默认方法，先调用映射，再手动校验结果 -
Service 层显式校验：将 DTO 作为入参传入 service，用注入的
Validator手动验证
例如：
@Service
public class OrderService {
private final Validator validator;
public OrderService(Validator validator) {
this.validator = validator;
}
public void create(OrderCreateDto dto) {
Set<ConstraintViolation<OrderCreateDto>> violations = validator.validate(dto);
if (!violations.isEmpty()) {
throw new IllegalArgumentException(violations.iterator().next().getMessage());
}
// 继续业务逻辑...
}
}
复杂校验逻辑（如字段间依赖、跨字段判断）怎么办？
用自定义约束注解，而不是构造块：
- 定义一个注解，比如
@ValidOrderTimeRange - 实现对应的
ConstraintValidator<ValidOrderTimeRange, OrderCreateDto> - 在 validate 方法里写完整逻辑：检查
startTime < endTime、是否在营业时段内等 - 把该注解加到 DTO 类上
这样既保持校验语义清晰，又可复用、可测试、可被框架统一管理。
