super关键字在多态中的使用方法

super关键字并非多态的“绕过开关”，而是编译器专为子类内部提供的静态绑定机制——它只在子类实例方法或构造器中有效，直接指向父类字节码方法，完全跳过虚方法表和运行时分派；外部调用永远遵循多态规则，任何试图用super让外界强制执行父类逻辑的做法都违背Java设计本质，真正的问题往往源于继承滥用，此时应反思设计：用final模板方法约束骨架、以策略模式替代硬编码继承，或转向组合优先原则。

Java里用super调父类被重写的方法，真能绕过子类逻辑？

能，但只在子类内部有效；外部调用永远走多态，super根本没机会出场。很多人误以为加个super就能让别人调到父类实现，其实它只是编译器给子类“开的后门”，仅限当前类方法体内使用。

• super.methodName()只能出现在子类的实例方法或构造器中，不能在静态上下文、lambda 或其他类里写
• 如果子类方法没重写父类方法，super.xxx()和this.xxx()行为一致（都走父类），但语义不同——前者明确意图，后者依赖继承链
• 编译器会把super.xxx()直接绑定到父类字节码里的方法符号，不经过虚方法表查找，所以不参与多态分派

为什么super在重写方法里调父类逻辑时容易空指针？

因为super本身不触发初始化，但它调用的父类方法可能依赖尚未完成初始化的字段。尤其当父类方法被设计为模板方法（比如init()里调doInit()），而子类重写了doInit()又反向依赖子类字段时，super.doInit()执行时子类字段还是null。

• 常见错误现象：NullPointerException发生在父类方法体里，但堆栈显示是子类重写方法被super调用的那一行
• 典型场景：父类构造器里调了可被重写的方法（如setup()），子类setup()访问了自己声明但还未初始化的final字段
• 解决办法不是避免super，而是别在父类构造器里调用非final、非private方法——这是Java初始化规则的硬限制

super和this混用时，方法解析顺序怎么算？

不看运行时对象类型，只看代码写的那一刻的静态类型和修饰符。编译器在编译期就决定super.xxx()去哪个类找方法，而this.xxx()是否多态，取决于该方法是否被重写且非static/final。

• 如果子类重写了foo()，this.foo()一定走子类版本；super.foo()一定走父类版本，哪怕父类的foo()也是从更上层继承来的
• 如果父类foo()是static，super.foo()和ParentClass.foo()等价，和this.foo()无关（静态方法不参与多态）
• 性能上没区别：super调用是静态绑定，JIT甚至可能内联；但滥用会导致维护困难——比如改了父类方法签名，子类super调用直接编译失败

多态环境下想让外部代码“强制”走父类实现，有替代方案吗？

没有安全通用的办法。Java的设计就是让引用类型决定行为，super不是访问修饰符，也不是运行时开关。所有试图“绕过”多态的尝试，本质都是在破坏封装或引入脆弱耦合。

• 常见错误尝试：把子类对象强转成父类类型再调方法——没用，只要方法被重写，还是走子类逻辑
• 可行但需权衡的做法：父类提供final委托方法（如public final void safeDo() { doImpl(); }），把可变部分抽成protected abstract doImpl()，这样外部只能调safeDo()，而子类无法改变其骨架
• 真正需要“切换实现”的场景，应该用策略模式或函数式接口，而不是靠super钻语言空子

最常被忽略的一点：super不是多态的“逃生舱”，它是子类对自己继承关系的显式声明。一旦你发现自己在反复纠结“怎么让别人调到父类”，问题往往出在设计上——父类职责太重，或者子类不该继承而该组合。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《super关键字在多态中的使用方法》文章吧，也可关注golang学习网公众号了解相关技术文章。