构造方法不能继承，但可被调用

Java中构造方法并非继承而来，而是必须由每个类自行定义，子类只能通过显式的super()调用父类构造器来参与对象初始化链——这一调用必须位于子类构造器第一行、不可省略、不可条件化，且与this()互斥；理解这一机制的关键在于破除“构造器可被继承”的误解，认清其本质是编译器强制的、单向的、自顶向下的委托调用链，稍有不慎便触发编译错误或运行时隐患，堪称Java初始化逻辑中最易踩坑却最不容忽视的核心规则。

构造方法根本不会被继承

Java里不存在“继承构造方法”这回事——子类不会自动获得父类的constructor，编译器也不会帮你把父类构造逻辑复制一份到子类里。这是很多初学者误以为“重写构造方法”或“子类能直接用父类构造器”的根源。

真正发生的是：每个类必须自己定义至少一个构造方法；如果没写，编译器才悄悄补一个无参的默认构造器（仅限该类本身没有显式定义任何构造器时）。

• 父类写了带参构造器、又没写无参构造器 → 子类extends它时，若不显式调用super(...)，编译直接报错：Constructor Xxx in class Yyy cannot be applied to given types
• 子类构造器第一行默认是super()，但这个调用只在父类有无参构造器时才合法
• 哪怕父类构造器是protected或public，子类也不能“继承”它来直接使用；只能通过super(...)显式委托调用

super() 必须是构造器第一句，且只能出现一次

这不是建议，是语法铁律。JVM要求对象初始化链必须从最顶层父类开始逐级向下执行，所以super()或this()必须是子类构造器的第一条语句。

• 如果写了super(...)，就不能再写this(...)，反之亦然
• 哪怕只是想先打印日志、校验参数，也得把super(...)挪到最前面——否则编译失败：call to super must be first statement in constructor
• 如果父类构造器抛出异常（比如IOException），子类构造器签名必须声明相同异常，或用try-catch包住整个构造体（但super()仍得在第一行）

子类构造器如何选择调用哪个父类构造器

取决于你传给super(...)的实参类型和个数，编译器按重载解析规则匹配父类中可见的构造器（public/protected/default，且非private）。

• 父类有A(String s)和A(int i)，子类写super("hello") → 绑定前者；写super(42) → 绑定后者
• 如果父类只有A(String s, int i)，而子类写super("x") → 编译失败，找不到匹配构造器
• 注意访问控制：父类构造器是private？那子类连super(...)都写不了，只能通过静态工厂或其他方式绕过

常见陷阱：this() 和 super() 的混淆与循环调用

用this(...)调用本类其他构造器，本质是“构造器重载的内部跳转”，但它和super(...)一样，必须是首句，且二者互斥。最容易栽跟头的是隐式调用链引发的无限递归。

• 构造器A里写this()，而this()指向的另一个构造器B里又写this()指向A → 编译期就报错：recursive constructor invocation
• 你以为加了if判断就能躲开？不行。this(...)或super(...)必须是字面量第一句，不能出现在条件分支里
• IDE有时会自动生成this(...)调用，但没检查参数是否真能终止链路——手写时务必画出调用图，确认每条路径最终都落到某个不调用this/super的构造器上

构造器调用链不是靠“继承”维系的，而是靠显式、单向、强制前置的super或this调用。最容易被忽略的，其实是父类构造器里可能执行了尚未初始化的子类字段（因为此时子类构造体还没跑），导致NPE或默认值误用——这点不在语法检查范围内，得靠调试和设计约束来防。

今天关于《构造方法不能继承，但可被调用》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！