构造方法不参与多态，因其无法被重写且调用由编译期静态决定；JVM根据new后的类名直接绑定构造器，不经过虚方法分派，全程无动态绑定。
构造方法不参与多态，因为根本没机会被重写或动态绑定
Java 中的构造方法 public MyClass()、MyClass(String s) 等，从语法上就不支持 override：它没有返回类型（连 void 都不能写），也不能加 @Override 注解。JVM 在对象实例化时，会根据 new 后面的字面类名（如 new SubClass()）**静态决定调用哪个构造器**，而不是看引用类型或运行时实际类型。所以谈不上“多态”——压根没进入虚方法分派流程。
常见错误现象：
– 试图在子类中用 @Override 标记构造方法 → 编译报错 Method does not override method from its superclass
– 以为 Parent p = new Child(); 会触发父类构造器的“多态调用” → 实际是先调 Child()，再隐式或显式调 super()，全程静态解析
构造器链本质是编译期确定的静态调用序列
每个构造方法第一行（除非显式写了 this(...) 或 super(...)）都会自动插入 super()。这个 super() 调用的目标构造器，在编译时就锁死了——比如 Child() 里调的 super()，永远指向 Parent()，哪怕后续 Parent 类被修改或存在多个重载版本，只要签名匹配，就是它。
- 参数差异直接影响能否编译通过：若
Parent只有Parent(int)，而Child()默认插super()就会报错Constructor Parent() is undefined - 如果手动写
super("abc")，则绑定到Parent(String)；写this(42)则跳转到本类另一个构造器 —— 这些全是编译期决策，和运行时对象无关 - 性能上无虚调用开销，但代价是灵活性归零：无法像普通方法那样靠子类重写改变行为
真正影响对象创建结果的是构造器执行顺序，不是多态
对象创建过程严格遵循“由父到子、由上到下”的初始化顺序：
1. 分配内存（此时字段为默认值：0 / null / false）
2. 调用父类构造器（递归向上直到 Object()）
3. 执行当前类字段初始化语句（如 int x = 5;）
4. 执行当前构造器剩余代码块
立即学习“Java免费学习笔记（深入）”；
这导致一个关键陷阱：
– 若父类构造器中调用了可被子类重写的方法（如 init()），该调用会走到子类实现，但此时子类字段尚未初始化（仍为默认值）→ 常见于 Spring Bean 初始化或自定义控件构建场景
– 示例：Parent() { init(); } + Child() { super(); int value = 10; } + Child.init() { System.out.println(value); } → 输出 0，而非 10
想实现类似“构造多态”的效果，得绕过构造器本身
如果业务需要根据参数/配置动态选择初始化逻辑，不要硬塞进构造器。更合理的方式是：
- 用静态工厂方法：
public static MyService createForEnv(String env) { return "prod".equals(env) ? new ProdService() : new MockService(); } - 用 Builder 模式：把复杂判断放在
build()内部，构造器保持精简、无逻辑 - 依赖注入容器（如 Spring）接管实例化：通过
@Profile、@Conditional控制 Bean 创建路径，而非靠 Java 语言机制
强行在构造器里做分支判断（如 if (type == A) {...} else {...}）会让类职责混乱，也掩盖了对象状态不一致的风险 —— 构造器唯一该干的事，是确保对象进入“可用”状态，而不是做策略分发。
