构造方法根本不会被继承
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）。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 父类有
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或默认值误用——这点不在语法检查范围内，得靠调试和设计约束来防。
