多态不是语法糖，而是设计能力的放大器；适用场景是运行时需动态决定同一语义范畴的行为且未来大概率新增，如支付策略；误用if-else式重写、错选抽象类/接口、调用失败因null/static/final/签名不一致等均违背其初衷。
Java多态不是语法糖，而是设计能力的放大器——用错地方会掩盖类型契约，用对了才能让扩展不改旧代码。
什么时候该用多态，而不是 if-else 或 switch
核心判断标准：是否需要在运行时动态决定行为，且这些行为属于同一语义范畴（比如“计算折扣”“发送通知”“解析格式”），同时未来大概率要新增同类行为。
- 适合多态：
PaymentStrategy接口下有AlipayStrategy、WechatPayStrategy、CreditCardStrategy，新增 Apple Pay 只需加个新类，不碰原有pay()调用逻辑 - 不适合多态：用户状态只有
ACTIVE/INACTIVE两种，且逻辑极其简单（如只设一个字段），硬套策略模式反而增加认知负担 - 警惕“伪多态”：所有子类重写方法但内部全是
if (type == X) { ... }，这等于把 switch 搬进了方法里，违背了多态初衷
抽象类 vs 接口：选错会导致后期重构成本翻倍
关键看“有没有共享状态或默认行为”。Java 8+ 后接口可有 default 方法，但不能有构造器、字段（除 public static final），也不能有 protected 成员。
- 用抽象类：多个子类共用初始化逻辑（如数据库连接池配置）、需定义
protected工具方法、或存在必须由父类控制的生命周期钩子（如templateMethod()中调用beforeExecute()和afterExecute()） - 用接口：纯粹的行为契约（如
Comparable、Runnable），或需要被不相关的类实现（如Serializable与业务逻辑无关） - 常见陷阱：在接口中塞大量
default方法来模拟抽象类，结果导致接口职责膨胀，违反单一职责；或者把本该是接口的契约强行做成抽象类，导致子类被迫继承无用字段
多态调用失败的三个隐蔽原因
编译通过但运行时没走预期子类方法？先查这三项：
apple-health-exercise-readiness
下载
查询苹果健康当日数据，分析身体状况是否适合锻炼，给出四档建议（重度/中度/轻度/建议休息）并附详细说明。使用 Python 处理数据。
立即学习“Java免费学习笔记（深入）”；
- 变量声明类型是父类/接口，但实际赋值对象为
null—— 调用时抛NullPointerException，而非进入子类逻辑 - 方法被
static、final或private修饰 —— 多态只适用于实例的非静态、非 final、非 private 方法 - 子类重写方法时签名不一致：比如父类是
void process(String data)，子类写成void process(Object data)，这其实是重载（overload），不是重写（override），JVM 不会动态分派
// 错误示例：看似重写，实为重载
class Processor {
void handle(List<String> items) { System.out.println("base"); }
}
class JsonProcessor extends Processor {
// 注意参数类型变了！这是重载，不是重写
void handle(List<Object> items) { System.out.println("json"); }
}
// 调用时：
Processor p = new JsonProcessor();
p.handle(Arrays.asList("a")); // 输出 "base"，不是 "json"
避免 instanceof + 强转：那是多态的倒退
一旦出现 if (obj instanceof Xxx) { Xxx x = (Xxx) obj; x.specificMethod(); }，说明抽象不够彻底，或者职责没划清。
- 正确做法：把
specificMethod()提到父类/接口中，哪怕子类实现是空方法或抛UnsupportedOperationException（需文档说明） - 折中方案：用访问者模式（Visitor）分离算法与数据结构，适用于操作类型稳定但数据结构常变的场景（如 AST 遍历）
- 真实约束下妥协：若必须区分类型（如日志上报需按设备类型走不同通道），优先用枚举字段 + 策略映射表，而非散落各处的 instanceof
最常被忽略的一点：多态的代价不在性能（现代 JVM 的虚方法调用优化已很成熟），而在于调用链路变长后，IDE 很难静态推导出最终执行的是哪个实现——这意味着你得靠测试和文档来守住行为边界，而不是靠编译器。
