多态是为解决“新增功能需修改老代码”问题而生，通过继承、重写和父类引用实现运行时动态绑定，仅对实例方法有效，适用于高频扩展场景。
多态不是炫技，是为了解决“新增功能要改老代码”这个痛点
你写了一个 pay() 方法支持微信和支付宝，老板突然说加云闪付——如果没用多态，你得打开原方法，加一个 else if ("UNIONPAY".equals(payType)) 分支。每次加新支付方式都要动同一段代码，一不小心就影响已有逻辑。多态的意义，就是让这种修改变成“只加类、不碰旧代码”：新增一个 UnionPay 类，继承 Payment，重写 pay()，调用方完全不用改。
为什么必须满足“继承 + 重写 + 父类引用”三个条件
缺一个，多态就失效：
- 没有继承关系 → 子类和父类毫无联系，JVM 不知道该找谁的方法
- 子类没重写
pay()→ 调用时还是执行父类的空实现或默认逻辑，行为没变化 - 没用父类类型声明引用，比如写成
WechatPay w = new WechatPay();→ 编译期就绑死在具体类上，失去统一调度能力
真正起作用的是运行时的动态绑定：JVM 看的是 new 后面那个真实对象类型，不是左边变量声明的类型。
最容易被忽略的坑：属性和静态方法没有多态
新手常误以为 animal.name 或 Animal.getCount() 也会按子类走，但实际：
立即学习“Java免费学习笔记（深入）”；
-
animal.name：编译和运行都看Animal类里有没有这个字段，子类同名字段只是隐藏（不是覆盖） -
Animal.getCount()：静态方法属于类本身，不参与动态分派，永远调用声明类型（左边）的类里的版本
所以多态只对**实例方法**有效，其他一律按声明类型查。
什么时候该用多态，而不是 if-else 或 switch
看扩展频率和维护成本：
- 支付方式、消息通知渠道、日志输出格式这类未来大概率要加新类型的场景 → 用多态
- 枚举值固定、生命周期极短的临时逻辑（比如某次活动的三种弹窗样式）→ if-else 更轻量
- 子类间行为差异极大，共性极少 → 强行抽象反而增加理解负担，不如拆开
多态的价值不在“看起来高级”，而在“改需求时，你敢不敢只提交一个新类文件就上线”。
