Java多态提升扩展性的核心是新增功能不改老代码：接口定契约、子类管实现、运行时自动选行为；结合Spring IoC与策略上下文，可热插拔扩展，但需警惕static/final/private、签名不一致、缺失@Override等导致多态失效的坑。
Java 多态在实际业务中提升扩展性的核心，是让新增功能不改老代码——接口定契约，子类管实现，运行时自动选行为。
用统一接口屏蔽差异，避免 if-else 膨胀
当一类业务存在多种变体（如支付、通知、导出、校验），直接写条件分支会导致逻辑耦合、难以维护。多态通过抽象出公共接口，把“做什么”和“怎么做”彻底分开：
- 定义 Payment 接口，声明
pay(Order order) - 各渠道实现：AlipayPayment、WechatPayment、PayPalPayment
- 订单服务只依赖
Payment类型，调用pay()即可 - 新增 ApplePay 支付？只需写一个新实现类，注册为 Spring Bean，主流程一行不改
结合 Spring 容器动态装配具体实现
Spring 的 IoC 天然支持多态扩展，无需手动 new 实例，靠类型自动匹配：
- 所有支付实现类加
@Service注解，并实现Payment接口 - 注入
List<Payment>或Map<String, Payment>，键为渠道编码（如 "alipay"） - 根据请求参数（如
channel="wechat"）从 Map 中取对应实例执行 - 后续加新渠道，只要保证 key 唯一、Bean 存在，路由逻辑完全复用
配合策略上下文封装选择逻辑
把“怎么选实现类”这个变化点收拢到一个地方，避免散落在各处的 switch 或 if：
立即学习“Java免费学习笔记（深入）”；
- 定义 StrategyContext 工具类，内部持有一个
Map<String, Function<?, ?>>或Map<String, Payment> - 提供
execute(String type, Object input)方法，统一做 key 查找 + 执行 - 新增策略时，只往 Map 里 put 一条映射，不碰 execute 主干
- 策略可来自配置文件或数据库，运行时热加载，连重启都不需要
警惕多态失效的常见坑
写了继承和重写，不代表多态就一定生效。这些细节决定扩展是否真正可靠：
- 方法被
static、final或private修饰 → 编译期绑定，无法动态分派 - 子类方法签名与父类不一致（比如参数类型不同）→ 实际是重载，不是重写
- 忘记加
@Override注解 → IDE 不报错，但可能因拼写错误导致重写失败 - 用
new WechatPayment().pay()直接调用 → 绕过接口引用，失去多态意义
