能，但仅限子类内部；外部调用永远走多态，super只是编译器为子类提供的静态绑定后门，不参与虚方法表查找，且不可在静态上下文或外部类中使用。
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。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 如果子类重写了
foo()，this.foo()一定走子类版本；super.foo()一定走父类版本，哪怕父类的foo()也是从更上层继承来的 - 如果父类
foo()是static，super.foo()和ParentClass.foo()等价，和this.foo()无关（静态方法不参与多态） - 性能上没区别：
super调用是静态绑定，JIT甚至可能内联；但滥用会导致维护困难——比如改了父类方法签名，子类super调用直接编译失败
多态环境下想让外部代码“强制”走父类实现，有替代方案吗？
没有安全通用的办法。Java的设计就是让引用类型决定行为，super不是访问修饰符，也不是运行时开关。所有试图“绕过”多态的尝试，本质都是在破坏封装或引入脆弱耦合。
立即学习“Java免费学习笔记（深入）”；
- 常见错误尝试：把子类对象强转成父类类型再调方法——没用，只要方法被重写，还是走子类逻辑
- 可行但需权衡的做法：父类提供
final委托方法（如public final void safeDo() { doImpl(); }），把可变部分抽成protected abstract doImpl()，这样外部只能调safeDo()，而子类无法改变其骨架 - 真正需要“切换实现”的场景，应该用策略模式或函数式接口，而不是靠
super钻语言空子
最常被忽略的一点：super不是多态的“逃生舱”，它是子类对自己继承关系的显式声明。一旦你发现自己在反复纠结“怎么让别人调到父类”，问题往往出在设计上——父类职责太重，或者子类不该继承而该组合。
