compact constructor 是入库前验证的唯一可靠入口，因其是 record 唯一可在对象创建时介入校验的合法位置，且必须在 this() 调用前完成检查；record 无初始化块或 post-constructor 钩子，组件 final 初始化后不可修改或拦截。
Record 的紧凑构造器（compact constructor）是唯一能在对象创建时介入校验的合法位置，它天然适配“入库前验证”场景——但必须在 this() 调用前完成检查，否则校验无效。
为什么 compact constructor 是入库前验证的唯一可靠入口
Record 没有传统类的初始化块或 post-constructor 钩子；所有组件在 this() 被调用后即被 final 初始化，不可再修改或拦截。这意味着：
- 校验逻辑若放在
this()之后，对象已构造完成，异常抛出也无法阻止实例存在（哪怕没赋给变量） - 不能依赖 setter、构建器模式或工厂方法替代——那已脱离 record 语义，且无法保证调用方一定走该路径
- 数据库 ORM（如 JPA/Hibernate）通常直接调用 canonical constructor，compact constructor 正是其实际执行点
compact constructor 中校验的实操要点
以一个用户注册数据为例：public record User(String email, int age) { ... }
校验需满足三个硬性条件：
- 校验代码必须写在
this()调用之前，例如：public User { if (email == null || !email.contains("@")) { throw new IllegalArgumentException("邮箱格式不合法"); } if (age 150) { throw new IllegalArgumentException("年龄超出合理范围"); } this(); // 必须显式调用，且必须在最后 } - 禁止对组件字段赋值（如
this.email = email.trim()），record 组件是 final，编译直接报错 - 异常类型建议用
IllegalArgumentException或IllegalStateException，避免 checked exception（record 构造器不支持 throws 声明）
和 Jackson 反序列化、JPA 入库的协同问题
Compact constructor 的校验在以下环节生效：
- Jackson 2.15.2+：启用
RecordModule后，反序列化会触发 compact constructor → 校验立即执行 - JPA（Hibernate 6.0+）：默认使用 record 的 canonical constructor，compact constructor 自动参与
- 手动 new 实例（如
new User("a@b", -5)）：校验同样触发，无需额外包装
但要注意：@NotBlank、@Min 等 Bean Validation 注解在 record 上**不会自动生效**——JSR-303 规范不强制要求验证框架调用 compact constructor，必须靠构造器内显式校验兜底。
容易被忽略的边界情况
真正上线后踩坑最多的是这两类：
- 空字符串 vs null：比如
email.trim().isEmpty()必须显式调用trim()，但 record 组件本身不会自动 trim —— compact constructor 是你唯一能做预处理的地方 - 集合类校验：如果 record 包含
List，需检查tags tags是否为 null，且不能用tags.isEmpty()替代非空判断，因为Collections.unmodifiableList(null)会 NPE
这些不是语法限制，而是数据契约落地时最常漏掉的细节。record 的简洁性会放大校验疏漏的影响——它不给你第二次机会改状态。
