this()调用必须位于构造器第一行，且与super()互斥；推荐主构造器作终点，复杂场景改用静态工厂或builder模式。
构造器里用 this() 调另一个构造器，必须是第一行
Java 规定：只要用了 this()，它必须出现在构造器代码的第一条可执行语句位置。编译器会直接报错，比如 Illegal constructor call 或更直白的 call to this must be first statement。
常见错误现象：
- 在
this()前写了变量声明、if判断、甚至注释（带执行逻辑的注释不算，但别这么写） - 试图在 try-catch 里调用
this() - 误以为可以像普通方法一样，在任意位置“跳转”到另一个构造逻辑
实操建议：
- 把所有参数预处理逻辑（如空值校验、默认值补全）挪到被调用的那个构造器里，而不是调用者里
- 如果真需要前置逻辑，考虑提取成
private static工具方法，在参数传入前就处理好 - IDE（如 IntelliJ）通常会高亮提醒，但别依赖——养成先写
this(...)再补逻辑的习惯
this() 和 super() 不能共存
一个构造器里只能出现 this() 或 super() 中的一个，且只能是第一条语句。这是 JVM 初始化机制决定的：对象创建时，必须明确走哪条继承链起点。
使用场景：
- 子类想复用父类某个带参构造器 → 用
super(...) - 本类有多个构造签名，想避免重复初始化逻辑 → 用
this(...) - 两者混用？编译直接失败，没有商量余地
容易踩的坑：
- 写了
super(...)后又加了this(...)，以为能“接力”，结果编译不过 - 删掉显式
super()后忘了父类没无参构造器，导致隐式调用失败，报no suitable constructor found - 抽象类或接口里误写
this()—— 构造器只属于具体类，抽象类可以有，但不能被直接实例化
链式调用深度没硬限制，但别绕晕自己
Java 不限制 this() 链的长度，理论上你可以 A→B→C→D 这样串四五个构造器。但实际中，超过三层就该警觉。
性能影响几乎为零 —— 所有构造器调用都在编译期确定，运行时就是普通方法调用栈，无额外反射或动态开销。
真正的问题是可维护性：
- 调试时堆栈里全是同个类的不同构造器，容易看漏初始化顺序
- 某个字段在 C 构造器里赋值，但你从 A 入口进，中间 B 没做任何事，很容易误判字段来源
- 单元测试要覆盖所有入口构造器，否则可能漏掉某条链上的边界逻辑
实操建议：
- 主构造器（通常是参数最多、最完整的那个）放在最后被调用，作为“终点”
- 用 IDE 的 “Find Usages” 查
this()调用链，确认是否形成闭环或遗漏分支 - 如果链里开始出现条件判断（比如根据 flag 调不同构造器），说明设计已超出手动链式范畴，该考虑 Builder 模式了
静态工厂方法比构造器链更灵活
当你发现为了支持各种参数组合，不得不写七八个构造器，每个都靠 this() 串着走，那大概率已经走在反模式边缘。
原因很实在：
- 构造器名固定（就是类名），无法表达意图，比如
new Date(String)和new Date(long)完全看不出区别 - 构造器不能返回子类型，而静态工厂可以返回实现类、缓存实例、甚至 null（虽然不推荐）
- 构造器链无法跳过某步初始化，但静态方法可以按需组合逻辑
示例对比：
public class Config {
private final String host;
private final int port;
private final boolean ssl;
// 构造器链容易膨胀
public Config(String host) { this(host, 8080, false); }
public Config(String host, int port) { this(host, port, false); }
public Config(String host, int port, boolean ssl) { /*...*/ }
// 更清晰的替代：静态工厂
public static Config http(String host) { return new Config(host, 80, false); }
public static Config https(String host) { return new Config(host, 443, true); }
public static Config custom(String host, int port, boolean ssl) { return new Config(host, port, ssl); }
}
这不是说构造器链错了，而是当它开始让你反复复制粘贴参数列表、或者同事读代码要数三遍才能搞清哪个字段在哪步设的，就该换种方式了。
最常被忽略的一点：构造器链解决的是「本类多签名复用」，不是「构建逻辑复杂化」。后者交给静态方法或 Builder，责任更干净。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
