在Java里，构造方法是对象诞生的入口，它承担着把外部依赖和数据注入到实例字段中的职责。合理设计参数传递方式，直接决定了类的易用性和后期的重构成本。很多看似简单的实体类，之所以越改越乱，往往是因为构造方法的参数列表没有随着业务增长而调整策略。
一、构造方法传递参数的基本机制
当使用 new 关键字创建对象时，Java 虚拟机会先分配内存，然后调用对应的构造方法。构造方法的签名决定了调用方必须提供哪些参数，编译器会根据形参类型和数量进行重载解析。如果类中没有显式定义任何构造方法，编译器会自动生成一个无参构造；一旦写了带参构造，默认无参构造就不再存在，需要手动补上。
在构造方法内部，可以使用 this 关键字区分同名字段与局部参数。这种写法在参数较多时非常直观，但要注意，构造方法里尽量不要把 this 引用泄露给别的线程或回调，否则对象可能还没完全初始化就被使用。下面的代码展示了一个基础的用户类如何通过构造方法接收姓名和年龄：
public class User {
private String name;
private int age;
// 构造方法接收两个参数
public User(String name, int age) {
this.name = name; // this.name 表示实例字段
this.age = age;
}
public void printInfo() {
System.out.println("姓名: " + name + ", 年龄: " + age);
}
}
上述写法在字段少的时候很清晰，调用方一眼就能看懂每个值的含义。但随着业务扩展，比如要加邮箱、手机号、注册时间等，构造方法的参数会迅速膨胀，这时候就需要更结构化的传递方案。
二、伸缩构造方法与构建者模式对比
面对多参数场景，一种传统做法是 telescoping constructor，也就是一层套一层的重载构造方法。第一个构造只收必填项，后面的构造逐步增加可选项并调用 this() 把参数往下传。这种做法不需要额外类，但调用时容易看错参数顺序，而且当参数类型相同时几乎没法区分。
更现代的做法是构建者模式（Builder）。它在类内部定义一个静态内部类，通过链式方法收集参数，最后调用 build() 返回目标对象。这样调用方写出来的代码像在描述配置，而不是记位置。下面用同一个 User 场景演示 Builder 写法：
public class User {
private String name;
private int age;
private String email;
// 私有构造，只允许 Builder 调用
private User(Builder b) {
this.name = b.name;
this.age = b.age;
this.email = b.email;
}
public static class Builder {
private String name;
private int age;
private String email;
public Builder name(String name) {
this.name = name;
return this;
}
public Builder age(int age) {
this.age = age;
return this;
}
public Builder email(String email) {
this.email = email;
return this;
}
public User build() {
// 这里可以做参数校验
if (name == null) {
throw new IllegalArgumentException("name不能为空");
}
return new User(this);
}
}
}
从可维护性看，Builder 明显优于伸缩构造，尤其当多数参数是可选时。但它的代价是要写更多模板代码，对只有两三个字段的类来说略显笨重。因此小对象用直接传参或少量重载即可，复杂聚合根才值得上 Builder。
三、参数校验与不可变设计
构造方法是做入参校验的最佳位置，因为对象一旦创建就应该处于合法状态。可以在构造方法开头集中检查空值、范围或格式，失败就抛异常，避免带病对象流入业务逻辑。结合 final 字段，还能让类变成不可变对象，天然线程安全。
下面的例子在构造方法里校验年龄范围，并把所有字段声明为 final。这样实例创建后就无法被修改，调用方可以放心在多线程间传递，也不用担心后续被误改。注意校验信息要用中文弯引号或文字描述，不要依赖英文双引号避免解析问题。
public class Account {
private final String id;
private final int balance;
public Account(String id, int balance) {
if (id == null || id.isEmpty()) {
throw new IllegalArgumentException("账户id不能为空");
}
if (balance < 0) {
throw new IllegalArgumentException("余额不能为负数");
}
this.id = id;
this.balance = balance;
}
public String getId() {
return id;
}
public int getBalance() {
return balance;
}
}
不可变对象配合构造期校验，是降低系统复杂度的有效手段。很多并发 Bug 都源于对象在别人手里被悄悄改掉，而把状态锁死在构造方法里就从根上消除了这类风险。
四、继承场景下的构造参数传递
在继承体系中，子类构造方法必须保证父类先完成初始化，因此第一行要么显式写 super(参数)，要么隐式调用父类无参构造。如果父类只有带参构造，子类就强制要求传参上去，这其实是把依赖约束暴露给了下层。
设计父类时，建议保留一个受保护的构造方法专门给子类用，或者把公共字段抽到一个基类的 Builder 里。这样扩展时不会被迫在子类写一堆重复赋值。下面展示子类如何把参数传给父类构造：
class BaseUser {
protected String name;
public BaseUser(String name) {
this.name = name;
}
}
class VipUser extends BaseUser {
private int level;
public VipUser(String name, int level) {
super(name); // 必须把name传给父类构造
this.level = level;
}
}
这种链式初始化保证了对象整体的一致性。如果父类构造做了校验，子类传入的值也会自然被检查，不会出现父类字段处于半初始化状态的情况。
五、实践中的选型建议
回到最开始的问题，Java 中如何使用构造方法传递参数，并没有唯一答案。字段少于四个、且基本都是必填时，直接用带参构造最省事；参数多且有大量可选配置，Builder 是更稳妥的选择；而在框架注入或序列化场景，有时还需要保留无参构造配合 setter 使用。
核心原则是让调用方的代码读起来不费脑，同时对象出生即合法。把校验放进构造、用 Builder 屏蔽顺序陷阱、用 final 锁定状态，这三件事做好，构造方法就从单纯的语法点变成了设计工具。