构造器不能被重写，理解其不属继承体系的原因

构造器在Java等主流面向对象语言中根本无法被重写，因为它压根不参与继承体系——既不会被子类继承，也不具备多态性；super()调用只是初始化链中的显式委托，而非多态分派，更不是覆盖父类行为；真正可灵活运用的是构造器重载与初始化逻辑抽取，而理解这一设计本质，能帮你避开模板方法失效、构建器模式误用、序列化陷阱等深层架构问题。

构造器不能被重写（override）

直接说结论：constructor 在 Java（以及多数主流面向对象语言如 C#、Kotlin）中**完全不能被重写**。这不是语法限制太严，而是设计上就“没这个概念”——重写（override）的前提是“父类方法被子类继承后重新实现”，而构造器压根不参与继承体系。

为什么 super() 调用不是重写？

很多人混淆了 super() 和重写：子类构造器里写 super(1, "abc")，看起来像在“覆盖”父类行为，其实只是显式调用父类某个构造器，属于初始化链的一环。

• 父类的构造器不会自动出现在子类的成员列表里，IDE 的“go to declaration”点不进去子类继承的构造器——因为它根本不存在
• super() 是编译器强制插入或你手动写的调用语句，不是多态分派，也不走虚方法表（vtable）
• 如果你删掉父类的无参构造器，而子类又没写 super(...)，编译直接报错：Implicit super constructor XXX() is undefined

那怎么实现“类似重写”的效果？

真要复用初始化逻辑，靠的是组合与重载，不是重写：

• 把共用初始化代码抽成 private void init(...) 方法，在多个构造器里调用
• 子类定义自己的构造器，按需调用 super(...)，再补充子类专属逻辑
• 避免在构造器里做复杂操作（比如 I/O、网络请求），否则难以测试和替换——这比“能不能重写”更实际地影响架构

例如：

class Parent {
    Parent(String name) { /* ... */ }
}
class Child extends Parent {
    Child(String name, int age) {
        super(name); // 必须第一行，且只能调用，不能“重写”
        this.age = age;
    }
}

重载（overload）才是构造器的正确打开方式

同一个类里定义多个构造器，参数不同，这是完全合法且高频的做法；但要注意它们之间是平级关系，不是父子覆盖。

• 无参构造器和全参构造器共存，是 overload，不是 override
• 如果父类只提供带参构造器，子类又没显式写构造器，编译器不会自动补无参构造器——这点常导致子类无法实例化
• Lombok 的 @AllArgsConstructor 和 @RequiredArgsConstructor 生成的也是重载构造器，不是对父类的重写

构造器不进继承链，这个事实会影响你设计模板方法、构建器模式甚至序列化逻辑——它不像普通方法那样能被动态绑定，所以别在构造阶段指望多态。

理论要掌握，实操不能落！以上关于《构造器不能被重写，理解其不属继承体系的原因》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！