父类构造方法中调用被子类重写的方法是危险但默认发生的多态行为；应避免在构造过程中依赖可被重写的行为，最稳妥方式是将方法设为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 规范保证）。靠调用顺序无法绕过这个底层约束，必须从设计层面规避。
