多态性是依赖倒置原则（DIP）得以实现的关键机制；它通过接口或抽象类的运行时绑定，使模块依赖于抽象而非具体实现，从而支持行为替换与解耦，缺失多态则DIP仅剩语法形式。
多态性是依赖倒置的实现基础
依赖倒置原则（DIP）要求模块之间依赖于抽象，而非具体实现；而 Java 中的多态性——尤其是通过接口或抽象类实现的运行时绑定——正是让这种“面向抽象编程”落地的关键机制。没有多态，new 一个具体类就直接耦合了实现，interface 或 abstract class 就只剩语法形式，无法在运行时替换行为。
依赖倒置必须配合多态才能生效
只声明接口不等于满足 DIP；只有当调用方真正通过多态方式使用该接口（比如参数类型、返回类型、字段类型为接口，且实际传入/返回的是其实现类），才能实现可插拔和解耦。否则就是“假抽象”。
- ✅ 正确：方法签名用
PaymentService接口，注入AlipayService或WechatPayService实例 - ❌ 错误：方法签名用
AlipayService，哪怕它实现了PaymentService，调用方仍被钉死在具体类上 - ⚠️ 常见陷阱：用
Object或泛型未约束类型（如T）代替接口，看似灵活，实则失去编译期契约和多态调度能力
Spring 的 @Autowired 本质是多态驱动的依赖倒置
Spring 容器能自动装配 PaymentService 类型的 Bean，前提是存在且仅存在一个该接口的实现类，或通过 @Qualifier 明确指定。这个过程依赖 JVM 的多态机制：容器持有的是接口引用，实际执行的是实现类的方法字节码。
public class OrderService {
private final PaymentService paymentService; // 接口类型字段
public OrderService(PaymentService paymentService) {
this.paymentService = paymentService; // 多态注入
}
public void pay(Order order) {
paymentService.execute(order); // 运行时动态绑定到具体实现
}
}
违反多态会直接破坏依赖倒置的效果
即使代码结构上写了接口和实现分离，只要在业务逻辑中出现硬编码的 new AlipayService()、类型强转（如 (AlipayService) service）、或用 instanceof 做分支判断，就等于在抽象层之下又挖了一条通往具体实现的隧道。
立即学习“Java免费学习笔记（深入）”；
- 性能影响不大，但彻底丧失替换能力：加个新支付方式就得改老代码
- 单元测试困难：无法用 Mock 实现类替换真实实现
- IDE 和静态分析工具无法识别潜在耦合点，问题延迟暴露
真正难的不是写接口，是在每一处对象创建、类型判断、方法调用里守住“只认接口”的边界——那里才是多态和依赖倒置交汇的真实战场。
