先讲一个核心思路：多态之所以能降低耦合，本质上靠的是“依赖抽象，而非具体实现”。调用方只看接口或父类，不跟某个具体子类绑死——这就像你订外卖只写“送一份快餐”，而不是指定“送一份宫保鸡丁盖饭”，厨房今天做什么菜，你都不用改订单。

说得直白点，调用方只认抽象（接口或父类），不绑定具体实现类，模块之间的强依赖关系自然就松开了。

依赖抽象，而非具体实现

代码里用接口或抽象类声明变量和参数时，调用逻辑就不再关心背后究竟是哪个子类在干活。举个例子：定义一个 Shape 接口，Circle 和 Rectangle 分别实现它；绘图方法接收 Shape 类型参数，根本不用管传进来的是圆还是矩形。什么时候新增一个 Triangle？只要老老实实实现 Shape，原有的绘图逻辑连一行代码都不用改。

新增功能无需修改旧代码

这就是开闭原则的落地——对扩展开放、对修改关闭。只要子类遵循父类或接口的约定（方法签名一致），运行时就能自动调到正确的实现。这种“插拔式”替换能力，相当于在代码里装了一个万能插座：你不需要在业务逻辑里反复写 if-else 或 switch 判断具体类型，自然就切断了调用方与实现类之间的硬编码捆绑。

动态分派屏蔽底层差异

JVM 在运行时根据对象的实际类型查虚方法表，决定跑哪个重写版本。这就意味着：编译期只检查父类或接口里有没有这个方法，真正执行什么逻辑，全看实例的类型。当然，静态方法、final 方法或私有方法不参与这个过程——只有那些可以被重写的、面向对象的行为，才能享受这种解耦红利。

协同开发更可控

多人协作的项目里，接口就是一份契约。前端团队按接口定义调用方式，后端团队各自实现不同服务（比如支付模块同时支持微信、支付宝、银联），只要都实现同一个接口，上层代码就能无缝切换。命名、参数、返回值全被约束住，风格不统一导致的集成问题大幅减少，跨模块沟通成本自然降下来了。