Java 25 灵活构造器怎么做参数校验：super 前置代码、this 规则与迁移边界

以前写 Java 子类构造器，想在调用 super(...) 前校验参数，通常只能把校验挪进静态工厂方法，或者先算好参数再传进另一个构造器。Java 25 的灵活构造器体特性改掉了这个固定顺序：构造器的 super(...) 或 this(...) 不再必须是第一条语句，但前置代码仍然不能随意使用正在创建的实例。

先看一个真实的构造器痛点

假设订单对象继承自一个需要金额的基类。旧写法里，子类只能先把金额校验放到静态方法或构造器参数表达式中，代码一长就容易把“校验”和“父类初始化”拆散。更麻烦的是，父类构造器如果调用了可重写方法，子类字段还可能处于默认值状态。

class Bill {
    Bill(long cents) {
        if (cents 

这个版本没有错，但校验逻辑只能藏在静态方法里。Java 25 允许把校验写回构造器的前置区，让参数准备和父类调用的顺序更直观。

Java 25 的 prologue 到底能做什么

构造器现在可以分成两个阶段：显式调用父类或本类构造器之前是 prologue，调用之后是 epilogue。前置区适合做不依赖实例的准备工作，比如校验方法参数、计算局部变量、规范化字符串，或者给当前类的字段赋值。

class PaidBill extends Bill {
    private final String channel;

    PaidBill(long cents, String channel) {
        if (cents 

这里的顺序很重要：金额和渠道在父类构造器运行前已经完成检查，父类如果间接触发子类的可重写行为，也不会再看到未准备好的 channel。字段赋值仍应保持简单，复杂副作用最好放到对象完全初始化之后。

三个容易踩到的限制

不能把它当成普通实例方法

prologue 里不能读取尚未完成初始化的实例状态，不能调用实例方法，也不能把 this 传给外部方法。能做的是给当前类字段赋值，以及使用参数、局部变量和静态方法。把一个校验函数从 static 改成实例方法，往往会立刻触发编译错误。

this() 仍然只能选一条构造器链

如果前置区最终调用的是 this(...)，被调用的本类构造器仍负责后续父类初始化。不要在一个路径里既调用 this(...) 又调用 super(...)；构造器链必须保证每条路径只完成一次父类初始化。

父类回调风险没有消失

这个特性解决的是“子类字段在父类构造期间仍是默认值”的一类问题，但父类构造器调用可重写方法本身仍然值得避免。前置赋值只能降低风险，不能把脆弱的继承设计变成安全设计。

从 Java 24 预览代码迁移到 Java 25

Java 24 中这项能力还是预览特性，构建脚本通常带有 --enable-preview --release 24。Java 25 迁移时先把版本改到 25，再删除只为该特性保留的预览开关；如果项目还使用其他预览特性，不能一次性全部删掉，应该按特性逐个确认。

• 搜索构建脚本里的 --enable-preview 和 --release 24。
• 检查前置区是否引用了实例字段、实例方法或外部可见的 this。
• 为正常参数、空值、异常参数和父类构造异常各写一个测试。
• 确认 IDE、静态检查器和格式化工具已经识别 Java 25 语法。

如果项目必须继续支持 Java 21 或 Java 17，不要把这段语法直接下沉到公共库。可以保留静态工厂方法作为兼容入口，或者继续使用传统构造器链，让编译目标决定是否启用新写法。

用测试确认构造器顺序

最小验收不需要复杂框架。至少覆盖成功创建、参数在父类调用前被拒绝、渠道被规范化、构造器链只走一次四类结果。测试里可以让父类记录收到的值，再断言异常发生时不会留下半初始化对象。

assertThrows(IllegalArgumentException.class,
    () -> new PaidBill(0, "card"));

var bill = new PaidBill(1299, " card ");
assertEquals("card", bill.channel());

如果代码由框架反射创建，还要补一条真实框架路径。构造器语法能编译，不代表序列化、依赖注入或代理生成器已经支持你的目标字节码版本。

常见问题

Java 25 的 Flexible Constructor Bodies 还是预览吗？

不是。Oracle 的 Java SE 25 语言变更表把它列为永久特性，JEP 编号是 513。

super() 前能调用静态校验方法吗？

可以，只要方法不依赖正在创建的实例，也不通过参数把 this 传出去。

这个特性能修复所有父类构造器回调问题吗？

不能。它让子类字段可以更早准备，但父类构造器调用可重写方法仍可能造成复杂耦合，优先考虑组合或不可重写的初始化路径。

Java 21 项目能直接使用这段语法吗？

不能把 Java 25 语法当作 Java 21 代码编译。需要升级编译目标，或继续使用静态工厂与传统构造器写法。

结语

Java 25 的变化不在于让构造器“更自由”，而在于把参数准备、字段初值和父类初始化的边界写得更接近真实业务顺序。迁移时先看构造器链和实例引用，再看构建工具与运行时版本；通过这两道检查，新语法才值得落到生产代码里。