真正能“强行锁定底层核心逻辑”的是final方法+jep 513显式超类调用+模板方法模式的三层组合：final封住不可变流程骨架，jep 513在多接口混入时精准锚定实现，模板方法内嵌super调用并配合final校验，三者协同确保控制流、语义与逻辑不可绕过或篡改。
在复杂多态继承体系中，真正能“强行锁定底层核心逻辑”的不是方法引用本身，而是 final 方法 + 显式超类调用（JEP 513）+ 模板方法模式 的三层组合。单纯靠 super.Xxx() 或接口方法引用无法锁定——它只负责调用，不阻止覆盖；而 final 才是真正的“锁”，JEP 513 则让这个锁在多接口混入场景下依然精准生效。
用 final 方法封住不可变流程骨架
核心逻辑若涉及顺序、校验、资源生命周期等关键环节，必须定义为 final。子类可继承、可扩展，但不能跳过或打乱主干流程。
- 把不变的执行序列写在
public final void execute()中 - 将可变环节声明为
protected abstract或protected（供子类重写） - 禁止子类重写
execute()，等于强制所有子类走同一套控制流
在接口默认方法冲突时用 JEP 513 精准调用目标实现
当多个接口提供同名默认方法（如 start()），子类实现类必须明确选择一个来源——这时 A.super.start() 不仅解决编译错误，更是一种“逻辑锚定”：它确保某段行为永远绑定到特定接口的原始定义，不受后续接口变更或新增默认方法干扰。
- 适用于组合式设计（如
Loggable & Retryable & Transactional） - 避免因接口升级导致子类意外切换到新默认实现
- 调用语句本身成为文档：此处必须用 A 的语义，不可替代
模板方法中嵌套 super 调用 + final 校验双保险
单靠 final 方法只能锁住入口，但某些校验或后置动作可能分散在不同层级。此时可在模板方法内部主动调用父类具体实现，并配合 final 封装该调用点：
- 例如在
process()中写super.preCheck();，同时将preCheck()声明为final - 这样既保留父类逻辑复用，又防止子类绕过或替换该检查
- 比纯抽象方法更严格：抽象方法允许子类自由实现，
final方法则只允许执行，不许动逻辑
避免常见误用：super 不是锁，只是通道
super.xxx() 本身不具备锁定能力——它只是调用语法。如果父类方法未被 final 修饰，子类仍可重写它，甚至在重写版本里跳过 super 调用。
- 不要以为写了
super.init()就万事大吉；要确认init()在父类中是否为final - 接口中的
default方法默认可被重写，除非你用 JEP 513 显式调用并配合final类方法约束调用上下文 - 真正起锁定作用的是修饰符和语言机制，不是调用形式
