构造方法重载必须满足：同一类中方法名相同（即类名）、参数列表不同（数量、类型或顺序至少一者不同）、与访问修饰符和返回值无关；本质是通过签名差异实现编译期唯一绑定。
构造方法重载不是“多写几个构造函数”就完事，关键在于让不同参数组合能自然对应到语义清晰、职责明确的初始化路径——否则容易变成参数爆炸或逻辑耦合。
Java 中构造方法重载必须满足的三个条件
重载生效的前提是编译器能唯一识别调用哪个版本，这依赖于严格的签名差异：
- 参数数量不同：比如
Person()、Person(String name)、Person(String name, int age) - 参数类型不同：比如
Person(String name)和Person(int id)（即使都只一个参数） - 参数顺序不同：比如
Person(String name, int age)和Person(int age, String name)（不推荐，易引发调用歧义）
注意：private Person() 和 public Person() 不能算重载——仅访问修饰符不同不构成重载；返回类型更不用提，构造方法本就没有返回类型。
this() 调用链必须指向最终实际赋值的构造方法
用 this(...) 做委托时，所有中间构造方法只是“跳板”，真正干活的必须是参数最全、完成全部字段赋值的那个。否则字段会漏初始化，尤其是当字段有默认值但你又没显式覆盖时：
public Person(String name) {
this(name, 0); // ✅ 正确：跳转到两参数版本
}
public Person(String name, int age) {
this.name = name;
this.age = age; // ✅ 这里才真正赋值
this.gender = "Unknown"; // ✅ 默认值也在这里设
}
反例：this(name) → this(name, 0) → this(name, 0, "Unknown") 是安全的；但如果中间某层自己写了字段赋值，又没调用 this(...)，就会和链路冲突，导致部分字段被覆盖两次或遗漏。
避免布尔参数和 null 值带来的语义模糊
当你写出类似 new Person("Alice", true) 或 new Person("Alice", null) 时，调用者根本看不出 true 代表“已婚”还是“启用账户”，null 是“性别未填”还是“不适用”。这类设计会让重载失去可读性：
- 用枚举替代布尔：定义
Gender.MALE/Gender.FEMALE/Gender.OTHER，再提供Person(String name, Gender gender) - 用 builder 模式替代多参重载：当参数超过 4 个且存在可选字段时，
new Person.Builder().name("Alice").age(30).build()比Person(String, int, String, boolean, LocalDate)更可靠 - 拒绝
null入参：在构造方法开头加Objects.requireNonNull(name, "name cannot be null")，而不是让它默默传下去造成后续 NPE
重载不是万能的，Go 和 Python 的处理方式很说明问题
Java/C++ 支持构造方法重载，但 Go 根本不支持函数重载，所以惯用法是用不同函数名区分初始化方式：NewPerson()、NewPersonWithName(name string)、NewPersonWithAge(age int)；Python 的 __init__ 也不支持传统重载，得靠 *args/**kwargs + 类型检查，或者用 @overload（仅用于类型提示，运行时无效）。
这意味着：重载是语言特性，不是设计银弹。真正需要关注的是——用户创建对象时，是否一眼就能看出该用哪个构造方法？字段约束是否在构造阶段就强制校验？后续会不会因为新增一个参数，就要补 2n 个重载版本？这些比“能不能写”更重要。
