新手必看：避免父类调用子类重写方法

父类构造方法中调用被子类重写的方法看似是多态的自然体现，实则暗藏严重风险：此时子类对象尚未完成初始化，若重写方法访问了未赋值的子类字段，极易导致空指针、默认值误用或逻辑错乱——这不是bug，而是设计陷阱；最根本的解决方案是避免在构造过程中依赖任何可被重写的行为，要么将关键方法声明为final/sealed从语言层面禁止重写，要么重构设计，把多态逻辑推迟到构造完成后的显式初始化方法中执行，从而在保障扩展性的同时彻底规避不可控的初始化时序问题。

直接说结论：父类构造方法中调用被子类重写的方法，是危险但默认发生的——这不是 bug，而是多态的自然表现；防止它，核心是**避免在构造过程中依赖可被重写的行为**。

为什么构造时调用子类方法很危险

父类构造器执行时，子类对象尚未完成初始化。此时若调用子类重写的虚方法（如 Java 的 non-final 方法、C# 的 virtual 方法、Python 的普通实例方法），而该方法又访问了子类自己的字段或资源，就可能读到未初始化的值（如 null、0、默认布尔值），甚至触发空指针异常或逻辑错误。

例如 Java 中：

• 父类 Super() 构造器里调用了 init()
• 子类 Base 重写了 init()，并在其中给 int i 加 1
• 但此时 i 还没被子类构造器赋初值，结果 i 可能是 0 → 加 1 后变成 1，看似正常，实则掩盖了“本应由子类构造器负责初始化”的责任错位

最稳妥的预防方式：把方法设为 final / sealed / 不可重写

这是从语言机制上堵死风险源头：

• Java：将父类中被构造器调用的方法声明为 final（如 final void init() { ... }），子类无法重写，也就不存在“调到子类去”的问题
• C#：用 sealed 修饰重写后的方法，或父类方法不加 virtual，或加 sealed override 阻断进一步继承
• Python：虽无语法强制，但可通过命名约定（如 _init_helper）+ 文档说明“此方法禁止在子类中重定义”，配合代码审查

替代设计：推迟可变行为到构造完成之后

不把需要多态的逻辑塞进构造器，而是拆成两步：

• 构造器只做安全、确定的初始化（如字段赋默认值、分配基础资源）
• 提供一个显式的初始化方法（如 initialize()、setup()），由使用者在对象构造完成后主动调用
• 这个方法可以是 virtual/abstract，放心让子类重写

这样既保留了扩展性，又把风险控制在开发者明确可控的时机。

额外提醒：别依赖 super() 调用顺序来“修复”

有人想“我在子类构造器第一行就调 super()，再初始化自己的字段，是不是就安全了？”——不完全。因为父类构造器内调用的方法，仍发生在子类字段初始化之前（JVM/CLR 规范保证）。靠调用顺序无法绕过这个底层约束，必须从设计层面规避。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《新手必看：避免父类调用子类重写方法》文章吧，也可关注golang学习网公众号了解相关技术文章。