compact constructor 是 record 中唯一能在 this() 前执行校验的合法位置，用于保障对象创建时状态合法；禁止赋值 final 字段，仅支持参数校验与异常抛出，统一用 IllegalArgumentException 或 IllegalStateException。
compact constructor 是唯一能介入 record 构造过程的校验点
record 没有 init 块、没有 post-constructor 钩子，所有组件在 this() 调用后即完成 final 初始化，不可拦截或修改。这意味着：校验逻辑若写在 this() 之后，实例已经构造成功，抛异常也拦不住对象存在；而 compact constructor 是编译器强制要求在 this() 前执行的唯一合法位置，天然契合“领域状态必须合法才允许存在”的 DDD 原则。
校验必须在 this() 调用前完成，且不能赋值字段
常见错误是试图在 compact constructor 中做归一化处理，比如 this.email = email.trim() —— 这会直接编译失败，因为 record 组件是 final，禁止显式赋值。正确做法是只读取参数、检查约束、抛异常：
- 检查空值、格式（如邮箱含
@）、范围（如年龄 0–150）、业务规则（如订单状态只能是"pending"或"shipped"） - 异常类型统一用
IllegalArgumentException或IllegalStateException，避免 checked exception（record 构造器不支持throws） - 若需 trim 或 toUpperCase 等标准化，必须用规范构造器（显式写出带参构造并调用
this(...)），但会失去部分自动生成优势，非必要不推荐
Jackson 和 JPA 入库时 compact constructor 会真实触发
很多人误以为加了注解（如 @NotBlank）就够了，但 JSR-303 不强制验证框架调用 compact constructor。实际链路是：
- Jackson 2.15.2+ 启用
RecordModule后，反序列化 JSON 到 record 会走compact constructor→ 校验立即生效 - JPA/Hibernate 6.0+ 默认使用 canonical constructor，
compact constructor自动参与，无需额外配置 - 手动
new UserDTO(" ", -5)同样触发 → 所有创建路径被统一兜底 -
@NotBlank等注解在 record 上**不会自动生效**，必须靠构造器内显式校验保底
DDD 场景下容易忽略的边界：聚合根 ID、状态迁移合法性
record 本身无法表达“状态机”语义，但可借助紧凑构造器拦截非法状态跃迁。例如订单从 "created" 直接到 "delivered" 是不允许的：
- 把状态字段声明为枚举（如
OrderStatus status），并在compact constructor中检查前序状态（需传入上下文，如上一个状态值） - 聚合根 ID 若需 UUID 格式，校验逻辑写在
compact constructor中比依赖 ORM 的@PrePersist更早、更可靠 - 注意：record 不能继承，也不能实现复杂的生命周期回调，复杂状态流转建议退回到普通 class，别硬套 record
