后期绑定指运行时根据对象实际类型决定调用哪个方法；Java中非static、非final、非private的实例方法默认后期绑定，字段和static方法则前期绑定，按声明类型解析。
后期绑定就是“运行时看对象实际类型再决定调用哪个方法”
Java 中绝大多数实例方法（非 static、非 final、非 private）都是后期绑定。这意味着：编译时只检查方法是否存在、参数是否匹配；真正调用哪个类里的实现，要等程序跑起来、看到 new 出来的到底是哪个子类对象，才做决定。
常见错误现象：Base b = new Derived(); b.method(); 却意外调用了 Base.method() —— 很可能是因为 method() 被声明为 static 或 final，触发了前期绑定，压根没走多态逻辑。
- 使用场景：所有向上转型 + 方法重写组合，比如
List list = new ArrayList(); list.add(...) - 性能影响：有轻微开销（JVM 需查虚方法表），但现代 JIT 优化后几乎可忽略
- 关键识别点：只要没被
static/final/private修饰，且不是构造方法，就默认后期绑定
前期绑定发生在编译期，和“写的是谁”强相关
前期绑定不看对象实际类型，只认变量声明类型或方法修饰符。它在编译阶段就锁死了调用目标，后续运行中不会改变。
典型误用：Base b = new Derived(); System.out.println(b.field); 打印的是 Base.field，哪怕 Derived 里定义了同名字段——因为字段访问是前期绑定，按静态类型 Base 查。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
static方法：b.staticMethod()实际调用的是Base.staticMethod()，哪怕b指向Derived实例 -
final方法：无法被重写，编译器直接绑定到父类实现，也关闭了动态分派 - 字段（含
public成员变量）：永远按引用类型解析，不存在多态
为什么 final 和 private 方法不能参与多态
private 方法隐式 final，子类根本看不到它，自然谈不上重写；final 方法则明确禁止重写。两者都让 JVM 在编译期就能唯一确定调用目标，跳过运行时类型判断。
容易踩的坑：private void init() { ... } 在父类中写了，子类也写了一个同签名 init() —— 这不是重写，而是两个完全无关的方法。父类里调用 this.init() 永远进不去子类那个。
- 子类中声明同名
private方法，只是“巧合同名”，和父类无任何绑定关系 -
final方法被子类继承后仍可调用，但调用的始终是父类版本 - 想强制关闭动态绑定？加
final是最明确的方式，比靠约定更可靠
验证绑定行为的最简方式：用同一引用调不同成员
写一个 Base 类和它的 Derived 子类，然后用 Base ref = new Derived(); 引用，分别访问字段、static 方法、普通实例方法——输出差异就是绑定机制的直接证据。
Base ref = new Derived(); System.out.println(ref.field); // 前期绑定 → Base.field ref.staticMethod(); // 前期绑定 → Base.staticMethod() ref.instanceMethod(); // 后期绑定 → Derived.instanceMethod()
字段和 static 方法输出父类内容，而实例方法输出子类内容，这个对比比任何理论都清楚。别依赖 IDE 提示或文档描述，亲手跑一次才是真理解。
真正的复杂点不在“怎么写”，而在“什么时候不该用后期绑定”——比如性能敏感的内循环里反复调用虚方法，或者需要确保逻辑绝对不可被子类篡改时，final 就不是限制，而是契约。
