Java多态从入门到实战：动态绑定、重写重载与避坑指南

多态是Java学习里最容易被"背会"却不一定"理解透"的一块内容。很多朋友能把"封装、继承、多态"这三个词背得滚瓜烂熟，但一问到底什么是多态、多态在JVM里怎么实现、为什么字段不参与多态，就答不上来了。这不太行，因为多态不只是面试八股文里的考点，它是几乎所有框架——Spring、MyBatis、JDBC、策略模式——的地基。这篇文章我打算用一套完整的笔记形式，把多态从概念到底层、从代码到面试、从经典案例到避坑经验全部串一遍，适合刚学完Java基础准备进阶的同学，也适合正在刷面试题打算系统梳理一遍的同学。

1. 多态到底是什么？先撕开这层窗户纸

1.1 一个例子说明白多态

先看一段最简单的代码：

java复制public class Animal {
    public void makeSound() {
        System.out.println("动物在叫");
    }
}

public class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("汪汪汪");
    }
}

public class Cat extends Animal {
    @Override
    public void makeSound() {
        System.out.println("喵喵喵");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal a1 = new Dog();
        Animal a2 = new Cat();
        a1.makeSound(); // 汪汪汪
        a2.makeSound(); // 喵喵喵
    }
}

这里的 Animal a1 = new Dog(); 就是多态的核心形态：编译期看左边，运行期看右边。变量 a1 的声明类型是 Animal，但真正指向的对象是 Dog。调用 makeSound() 的时候，JVM 在运行期发现你实际创建的是 Dog，于是去执行 Dog 的重写方法，打印"汪汪汪"。

多态说白了就是一句话：同一个行为，不同的对象去执行，会有不同的结果。这个"同一个行为"是调用入口层面的统一，"不同的结果"是具体实现层面的分裂。而 Java 里能让这种"分裂"成立的机制，就是继承、重写和动态绑定。

1.2 为什么需要多态，它能解决什么问题

如果没有多态，代码会写成什么样子？你可能会写出这种：

java复制public void makeAnimalSound(Animal animal) {
    if (animal instanceof Dog) {
        System.out.println("汪汪汪");
    } else if (animal instanceof Cat) {
        System.out.println("喵喵喵");
    } else {
        System.out.println("动物在叫");
    }
}

每加一种新动物，就要往这个方法里塞一个 else if。如果项目里有十处地方都要调用这个逻辑，你就得改十处。这种代码写多了，你会发现它不仅在折磨你的手，更在折磨你的设计能力——你随时可能漏改一处，然后线上就出了 bug。

而有了多态，这个方法就变成了：

java复制public void makeAnimalSound(Animal animal) {
    animal.makeSound();
}

新加一种 Pig，你只需要让 Pig 继承 Animal 并重写 makeSound()，上面的 makeAnimalSound 方法一行都不用改。这就是多态最核心的价值：面向抽象编程，而不是面向具体实现编程。你依赖的是 Animal 这个抽象，而不是 Dog、Cat 这些具体类。调用方和实现方彻底解耦，扩展性一下子就打开了。

1.3 多态的三种形态

平时常说的"多态"其实分好几种，面试时如果能区分清楚，是很加分的：

前两种是运行时多态，靠的是继承/实现接口加方法重写；最后一种泛型是编译期多态，编译时就已经确定了类型行为。面试时把这个分类讲清楚，比笼统地说"多态就是多种形态"要立体得多。

2. 必须吃透的两个底层机制：向上转型与动态绑定

2.1 向上转型为什么安全

初学者最容易疑惑的一个点是：Animal a1 = new Dog(); 为什么能这样写？Dog 明明是 Animal 的子类，Java 不是强类型语言吗？

这里的关键在于子类是父类的一种。狗是动物，这是生活常识，也是面向对象里 is-a 关系的体现。Dog 继承了 Animal，那么 Dog 就拥有 Animal 的所有属性和行为，编译器可以确定：你通过 Animal 这个类型的引用能调用的所有方法，Dog 一定都有。正因为这种"有"是确定的，所以向上转型是安全的，编译器允许你做这种宽化转换。

向上转型的安全性可以用一句话记忆：你永远不可能通过一个父类引用去调用一个子类才有、而父类没有的方法。因为编译器在编译期只认声明类型 Animal，它检查的是 Animal 类里有哪些方法。如果你试图写 a1.fetch()，而 fetch() 是 Dog 独有的，那么编译直接报错。

所以向上转型表面上是"把一个子类对象当成父类来看"，实质上是收窄了能调用的方法集合，但保留了对象真正的运行时类型。这个"保留"就是后面动态绑定的前提。

2.2 动态绑定：JVM 在运行期到底做了什么

动态绑定（也叫后期绑定、运行时绑定）是多态能真正生效的底层机制。为了理解它，先要知道 Java 方法调用的两种绑定方式：

• 静态绑定：编译期就确定调用哪个方法。典型代表是 static 方法、private 方法、final 方法，还有重载方法的匹配。因为这些事情在编译期就已经"尘埃落定"，不会因为对象实际类型而改变。
• 动态绑定：编译期不确定调用哪个方法，要等运行期根据对象的实际类型来决定。典型代表就是重写方法。

JVM 在类加载完成后，会为每个类生成一个方法表，里面记录了该类所有方法的实际入口地址。当执行 a1.makeSound() 时，JVM 根据 a1 真正指向的对象类型定位到 Dog 类的方法表，从中找到 makeSound() 的入口地址，然后调用。这个查找过程发生在运行期，所以叫"动态"。

用一个例子来看重载和重写的绑定时机差异：

java复制public class Demo {
    public static void main(String[] args) {
        Animal a = new Dog();
        print(a);
    }

    public static void print(Animal animal) {
        System.out.println("接收 Animal");
    }

    public static void print(Dog dog) {
        System.out.println("接收 Dog");
    }
}

猜猜会打印什么？答案是"接收 Animal"。因为 print 的两个方法属于重载，重载的匹配发生在编译期。编译器看到 a 的声明类型是 Animal，于是直接匹配到 print(Animal)。等到运行期，JVM 不会因为 a 实际指向 Dog 而重新选择 print(Dog)。重载是静态绑定，重写是动态绑定，这个差异特别容易在面试题里出现，稍后我会在常见问题里再展开。

2.3 你踩过的"多态失效"现场：字段和静态方法不参与多态

动态绑定只对实例方法生效，对字段和静态方法是不生效的。这一点非常反直觉，值得单独拿出来讲。

java复制public class Animal {
    public String name = "Animal";
    public static void hello() {
        System.out.println("Animal.hello");
    }
}

public class Dog extends Animal {
    public String name = "Dog";
    public static void hello() {
        System.out.println("Dog.hello");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();
        System.out.println(a.name); // Animal
        a.hello();                  // Animal.hello
    }
}

字段不参与多态，是因为 Java 在访问字段时，只看声明类型，不看实际类型。a 的声明类型是 Animal，所以 a.name 访问的是 Animal 里的 name，而不是 Dog 里的 name。这一点其实从设计上很好理解：字段是状态，方法才是行为。多态关注的是行为的不同表现，如果字段也跟着"多态"，那各种继承关系下的状态访问会乱成一锅粥。

静态方法不参与多态的原因更简单：静态方法属于类，不属于对象。a.hello() 本质上等同于 Animal.hello()，跟 a 指向的实际对象没有任何关系。这也是为什么很多代码规范会强调"不要用对象引用去调静态方法，直接用类名调用"，因为对象引用调静态方法不仅让人困惑，而且容易让人误以为它也有多态行为。

3. 重写与重载：多态的主战场细节越抠越稳

3.1 重写的五条硬规则

重写是多态的核心前提之一，规则记不牢，代码跑着跑着就出问题。我整理成五条硬规则：

1. 方法签名必须一致：方法名、参数列表必须完全相同。参数列表不同不叫重写，叫重载。
2. 返回类型可以变，但必须是原返回类型的子类型：这个叫"协变返回类型"。比如父类返回 Animal，子类重写时可以返回 Dog，从 Java 5 开始支持。
3. 访问修饰符不能比父类更严格：父类是 protected，子类重写时只能是 protected 或 public，不能降到 private。理由是：子类继承父类后，父类的方法能访问的地方，子类方法也必须能访问，否则里氏替换就不成立了。
4. 不能抛出比父类更宽泛的受检异常：这里的"宽泛"指异常类型的继承关系。父类声明 IOException，子类可以抛 FileNotFoundException（它是子类），但不能抛 Exception（它是父类）。如果父类没声明任何受检异常，子类也不能新增。
5. static 方法不能被重写，final 方法不能被重写，private 方法不能被重写。private 方法不是"不能"，是子类压根看不到它，所以谈不上重写。子类里写一个同名同参的 private 方法，那只是一个同名的新方法，不会触发动态绑定。

第 3 和第 4 条是很多人在代码规范审查里被重点检查的。理解它们不需要死记，抓住两个本质就行：向上转型要成立、调用方不能因为"换了子类实现"而出现编译或运行异常。

3.2 重载、重写差异实操视角

重载不是多态吗？这个问题的正确答案是：重载是编译期的"静态多态"，重写是运行期的"动态多态"。但在 Java 社区里，大家默认讨论"多态"时指的是运行期多态，也就是重写。所以面试时被问"重载算多态吗"，最好先说明语义，再给结论：从广义上讲算，从 Java 的多态机制上讲，重写才是核心。

从代码层面看，几个典型差异：

重载有一个必须避免的坑：只改返回类型不算重载。如果两个方法方法名相同、参数列表相同、只有返回值不同，编译器直接报错。理由是 Java 方法调用时，先根据方法名和参数列表去匹配，返回值不是匹配依据。int foo() 和 String foo()，编译器根本不知道该调哪个。

3.3 构造器调多态方法：一个很经典的坑

我要重点写一写这个坑，它在真实的代码 review 里出现过无数次，面试也爱问。看这段代码：

java复制public class Parent {
    public Parent() {
        init();
    }

    public void init() {
        System.out.println("Parent.init");
    }
}

public class Child extends Parent {
    private String name = "child";

    public Child() {
        // 这里其实会先调用 super()，也就是先执行父类构造器
    }

    @Override
    public void init() {
        System.out.println("Child.init, name = " + name);
    }
}

public class Main {
    public static void main(String[] args) {
        new Child();
    }
}

执行结果是什么？你会看到 Child.init, name = null。这里发生了两件事：

1. 创建 Child 对象时，会先调用 Parent 的无参构造器，即 super()。
2. Parent 构造器里调用了 init()，由于动态绑定，实际执行的是 Child 重写的 init()。
3. 此时 Child 的 name 字段还没有被赋值——因为 name = "child" 这个初始化代码在构造器里执行，而构造器里的初始化语句是在 super() 之后才跑的。

所以 name 打印出来是 null。这种问题很难排查，因为它不会报错，只会给出一个"看起来很奇怪"的结果。它本质上暴露的是一个设计问题：不要在构造器里调用可被重写的方法。

如果父类构造器确实需要初始化逻辑，应该把逻辑放到 private、final 或 static 方法里，这样就不会触发子类的重写。这是一个从入门到工作都很值得记住的规范，写代码时多留一个心眼。

3.4 向下转型与 instanceof：如何安全地把形状变回来

向上转型让我们可以"以小看大"，但有时候我们确实需要"把大形状变回小形状"——比如 Animal 引用实际指向的是 Dog，而我们需要调用 Dog 独有的 fetch() 方法。这时候就需要向下转型。

java复制Animal a = new Dog();
if (a instanceof Dog) {
    Dog dog = (Dog) a;
    dog.fetch();
}

向下转型最怕的是 ClassCastException。比如：

java复制Animal a = new Dog();
Cat cat = (Cat) a; // 运行期异常：ClassCastException

因为 a 实际指向 Dog，Dog 和 Cat 之间没有"血缘关系"，强行把自己当成 Cat 是会被 JVM 识破的。所以向下转型之前，一定要用 instanceof 做类型检查。

从 Java 16 开始，instanceof 支持了模式匹配，写法更简洁：

java复制Animal a = new Dog();
if (a instanceof Dog dog) {
    dog.fetch();
}

这个语法省掉了强转，读起来也清晰很多。如果项目用了 Java 16 及以上，推荐直接这么写。

4. 实操案例：从动物叫到策略模式，写出可扩展的代码

4.1 经典案例：模拟支付系统，用多态消灭 if-else

光说理论不落地，总觉得缺了点什么。我们一起来做一个更贴近实际开发的多态案例：一个支付系统。

问一个问题：如果让你写一个支付方法，支持支付宝支付、微信支付、银联支付，你会怎么写？最容易想到的写法是：

java复制public void pay(String payType, double amount) {
    if ("alipay".equals(payType)) {
        System.out.println("支付宝支付 " + amount + " 元");
    } else if ("wechat".equals(payType)) {
        System.out.println("微信支付 " + amount + " 元");
    } else if ("unionpay".equals(payType)) {
        System.out.println("银联支付 " + amount + " 元");
    } else {
        throw new IllegalArgumentException("不支持的支付方式");
    }
}

这个写法有一个致命的问题：每增加一种支付方式，就要改这个方法，加一个 else if。如果这段支付逻辑散落在好几个 Service 里，你得把每个 Service 都改一遍，漏改一个就出 bug。而且随着支付方式越来越多，这个方法会膨胀成一个几百行的怪物，readability 几乎为零。

用多态重构一下：

java复制public interface Payment {
    void pay(double amount);
}

public class Alipay implements Payment {
    @Override
    public void pay(double amount) {
        System.out.println("支付宝支付 " + amount + " 元");
    }
}

public class WechatPay implements Payment {
    @Override
    public void pay(double amount) {
        System.out.println("微信支付 " + amount + " 元");
    }
}

public class UnionPay implements Payment {
    @Override
    public void pay(double amount) {
        System.out.println("银联支付 " + amount + " 元");
    }
}

然后调用方只需要依赖 Payment 接口：

java复制public class PayService {
    public void pay(Payment payment, double amount) {
        payment.pay(amount);
    }
}

业务代码里这样用：

java复制Payment payment = new Alipay();
payService.pay(payment, 100.0);

新增银联支付时，只需要新建 UnionPay 类实现 Payment 接口，PayService 一行不用改。这就是面向接口编程的甜头。

4.2 升级案例：工厂模式加多态，把对象创建也隔离掉

上面的例子还有一个小问题：调用方在创建支付对象时，还是要用 new 来决定具体类型。也就是说，不同的支付方式虽然被多态隔离了，但创建对象的地方还是散落的。真正到了大型项目里，通常会在 Payment 多态之上，再套一层工厂模式，把"创建哪种支付对象"这个决策也集中起来：

java复制public class PaymentFactory {
    public static Payment create(String payType) {
        return switch (payType) {
            case "alipay" -> new Alipay();
            case "wechat" -> new WechatPay();
            case "unionpay" -> new UnionPay();
            default -> throw new IllegalArgumentException("不支持的支付方式");
        };
    }
}

这样，业务代码只需要：

java复制Payment payment = PaymentFactory.create("alipay");
payService.pay(payment, 100.0);

if-else 被压缩到了工厂这一个地方。以后新增支付方式，只需要改 PaymentFactory 一个文件，或者在配置中心注册一个新的实现类，业务代码完全不受影响。

这种"多态 + 工厂"的组合在 Spring 里随处可见。你平时写 @Autowired List<Payment> paymentList，然后把所有支付实现类注入进来，本质上就是利用了多态的特性，把不同的实现类统一收口到接口集合里。这是我在实际框架里见过最多的多态应用场景之一。

4.3 案例对比：三种写法的演进过程

用一个表格来总结这个支付系统的演进过程，方便大家对比：

很多朋友问我，是不是只要看到 if-else 就要改成多态？我的看法是不必走极端。分支少、变化少的地方，if-else 反而比过度抽象更易读。多态和工厂的引入，是为了应对变化——如果你明确知道这个场景的扩展频率很高、实现类会越来越多，那一开始就设计成多态，后面会舒服得多。

5. 面试八股大盘点：高频追问与高质量回答思路

5.1 高频问题与参考回答速查

多态是 Java 面试必考题，围绕它的追问可以层层递进。我把常见的面试题整理成一张速查表，每个问题附上回答要点：

第 8 条值得补充一句：super.method() 只能访问直接父类的实现，不能跨越多个层级。如果你的代码里出现大量 super 调用，通常是类设计出了问题——子类过于依赖父类实现，耦合度太高。

5.2 如何答出区分度：从八股到源码意识

面试官问"多态的实现原理"时，大部分人的回答就是"方法重写 + 动态绑定"。这个回答不算错，但没有区分度。想拿高分，可以再往深说一点点，提一下 JVM 方法表机制和可能发生的优化。

具体来说，JVM 调用一个方法时，如果方法没有被重写，走的是虚方法表查找；随着 JIT 编译器的介入，为了提升性能，HotSpot 会做内联缓存和方法内联优化。比如一个调用点长期只接收 Dog 类型的对象，JIT 可能会把方法调用直接替换成 Dog.makeSound() 的入口，省去查找过程；但如果接下来来了一个 Cat 对象，JIT 发现类型变了，会放弃缓存，回退到查虚方法表。这个机制叫做"去优化"。

这些内容不需要背具体源码，但能讲明白这个思路，面试官一眼就能分辨出你是真正学过 JVM，而不是死记硬背概念。如果被追问"虚方法表是什么"，可以答：每个类在类加载阶段生成一张表，表的每一项对应一个方法，记录方法执行的入口地址；子类重写父类方法时，方法表里对应槽位的入口地址会指向子类实现。这个结构让动态绑定在性能上比反射快得多，也是 Java 多态能大规模应用的基础。

5.3 面试中的手撕题目思路

除了问原理，面试官还可能现场出题考察多态的运用能力。最典型的两类题目：

第一类是"用多态重构一个功能"。比如给出上面那个支付系统的 if-else 版本，让你用多态改造。这时候建议先说清楚思路，再动手写：定义接口、为每种方式写实现类、在调用方改为依赖接口。如果时间允许，可以顺手讲一下我会配合工厂模式来统一对象创建逻辑。

第二类是"判断输出结果"。例如：

java复制class A {
    public String show() {
        return "A";
    }
}
class B extends A {
    public String show() {
        return "B";
    }
}
public class Test {
    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.show());
    }
}

答案是 "B"。但如果把 show 改成 static，答案就变成 "A"。这种题目考的就是"实例方法看运行期类型，静态方法看编译期类型"这个核心点。写答案之前先判断方法是不是静态的、是不是 private 的、是不是 final 的，这三点决定了它是否参与动态绑定。

6. 实战中的避坑指南：这些坑每一个我都踩过

6.1 强转前的 instanceof 判断永远别省

我见过最典型的生产事故之一，就是"从缓存里取出来的对象强转成某个类型，结果 ClassCastException 直接打崩接口"。场景通常是：项目早期往缓存里塞了一个对象，后期某天重构了对象模型，或者换了序列化方式，再取出来的时候类型对不上，强转就炸了。

用多态代码的语境下，向下转型先 instanceof 不是建议，是规范。写了 instanceof 判断，至少能保证强转安全。同时要记得，instanceof 判断的左侧对象如果是 null，结果直接是 false，不会抛空指针。所以放心用：

java复制Animal a = getAnimalFromCache();
if (a instanceof Dog dog) {
    dog.fetch();
} else {
    // 兜底逻辑
}

6.2 重载绑定的是编译期类型，不是运行期类型

这个坑我在 2.2 里已经提到过，但因为它实在太经典，我把它放到避坑指南里再强调一次。写代码的时候，凡是牵扯到"重载方法 + 多态对象"的组合，都要在心里过一遍"编译器用的是哪个类型"。

举个例子：

java复制public class Demo {
    public void execute(Animal animal) {
        System.out.println("execute Animal");
    }

    public void execute(Dog dog) {
        System.out.println("execute Dog");
    }

    public static void main(String[] args) {
        Demo demo = new Demo();
        Animal a = new Dog();
        demo.execute(a); // 打印 execute Animal
    }
}

如果你期待打印 execute Dog，那说明你把重载的静态绑定和重写的动态绑定搞混了。execute 是重载，编译器在编译 demo.execute(a) 时看到 a 的声明类型是 Animal，所以直接匹配 execute(Animal)，运行期不会重新选择。这种题在笔试里出现频率极高，但放到真实项目中，它提醒我们的是一件事：不要用编译期类型不确定的变量去调重载方法，否则行为很容易跟直觉不一致。

6.3 多态好，但别滥用：区分"变化点"再动手

前面鼓励大家用多态替代 if-else，但这里也得泼一盆冷水：如果业务场景本身没有扩展可能，强行上多态只会增加代码的阅读难度。

举个例子，一个方法里只判断一个布尔值决定走 A 逻辑还是 B 逻辑，这种场景完全没必要抽象两个类出来。如果强行抽象一个 Strategy 接口，再写 AStrategy、BStrategy，将来别人看代码时点开三个类，发现里面逻辑加起来还不超过二十行，会觉得你在过度设计。

那什么时候值得引入多态？我的判断标准是看变化点是否明确且频繁。支付方式、数据源类型、消息队列实现、日志输出策略这类天然存在多个实现且经常扩展的场景，多态是标配。而一次性脚本、内部工具类的简单判断，用 if-else 反而干净。多态是工具，不是信仰，能解决问题的方案才是好方案。

6.4 小心"协变返回类型"带来的困惑

前面提到协变返回类型是 Java 5 开始支持的，子类重写方法时可以返回父类返回类型的子类型。这个特性在不经意间会带来一些小困惑。

java复制public class Parent {
    public Animal get() {
        return new Animal();
    }
}

public class Child extends Parent {
    @Override
    public Dog get() {
        return new Dog();
    }
}

这个代码是合法的，Dog 是 Animal 的子类。但有个细节要注意：虽然返回类型可以变，方法签名里的参数列表不能变。有朋友把协变返回类型理解成"参数也能变"，那就错了。参数列表变了就不是重写，而是重载，@Override 注解会直接报错。

我在给同事做 code review 时，偶尔会看到这种情况：子类方法把返回类型从接口改成实现类，导致一些依赖父类返回类型的调用方代码出现编译错误。其实这不是协变返回类型的问题，而是调用方的变量声明类型太具体。如果你用 Animal animal = child.get() 来接返回值，那子类返回 Dog 完全 OK；如果你用 Dog dog = child.get()，那父类返回类型是 Animal，编译都不带过的。所以，声明类型尽量抽象，接收类型尽量具体这个问题，要分场景看，别一刀切。

6.5 序列化和多态的结合坑：反序列化时类型丢失

最后分享一个跟实际项目强相关的坑。当多态对象经过 JSON 序列化再反序列化时，经常会发生"壳还在，瓤丢了"的情况。

java复制Payment payment = new Alipay();
String json = objectMapper.writeValueAsString(payment);
// 反序列化时，如果只声明成 Payment 类型
Payment restored = objectMapper.readValue(json, Payment.class);

如果 Payment 是接口，这种写法会直接报错，因为 Jackson 无法实例化接口。就算 Payment 是抽象类或普通父类，反序列化出来的对象也大概率是 Payment 类型，而不是原来的 Alipay——也就是说，动态绑定信息在一次序列化往返之后丢了。

解决方法也简单，几种思路：

1. 在 JSON 中携带类型信息，比如在类上配置 @JsonTypeInfo(use = Id.CLASS)，告诉 Jackson 序列化时把类名写进去。
2. 手动指定反序列化目标类型，用 TypeReference 重载格式。
3. 如果传输链路不复杂，干脆传 DTO，不做多态对象的序列化，这是最省心的方式。

这个坑在多态相关的技术方案设计里很少被人提起，但遇到一次就很疼。大家提前有个印象，以后碰到"接口数据下发后类型不对"的问题，能第一时间定位到序列化这里。

7. 从多态看整个面向对象设计

写到这里，多态的核心机制、实操案例、面试要点和避坑经验都覆盖到了。最后我以一个过来人的角度，说说我自己在项目里慢慢体会到的经验。

我第一次学到多态时，也觉得这就是语法层面的"继承 + 重写"。但后来参与的项目越来越大，我慢慢意识到，多态真正的价值不在语法，而在它背后传递的设计哲学：依赖抽象，而不是依赖具体实现。所有谈多态的书，最后几乎都会落到这个原则上。Payment 接口的本质，就是让上层代码不依赖具体的支付渠道；Animal 类的本质，就是让调用方不依赖具体的动物种类。你把这个原则想通了，再去理解 IoC、理解依赖注入、理解 Spring 里那一大堆"配置切换实现"的机制，都会有一种豁然开朗的感觉。

另外，多态里还有很多"反直觉"的小知识点，比如字段不参与多态、静态方法不参与多态、重载是编译期绑定。这些点在实际编码中很难察觉，但在面试和问题排查中就是拉开差距的细节。建议大家学完这块后，亲手写几个小 demo 验证一遍，比如把方法改成 static 试试输出变化，在构造器里调用重写方法看看 null 值——亲自踩过一遍，记忆比背十篇笔记都牢固。

最后再分享一个小技巧：写类和方法时先问问自己——这个类会被扩展吗？这个方法会被子类重写吗？如果答案很可能为"是"，就尽量给方法留出重写的余地，不要动不动就加 final；如果答案很明确为"否"，那 final 反而是一种清晰的工程意图表达。多态不是越多越好，把抽象用在真正需要变化的地方，才算真正把多态用明白了。