Java多态是API开发中实现高内聚、低耦合的核心能力，通过接口定义服务入口、Spring多态注入、策略模式封装行为及泛型增强兼容性，支撑RESTful服务等场景。
Java 多态在 API 开发中不是“锦上添花”，而是支撑高内聚、低耦合服务设计的核心能力。它让接口层能统一处理不同业务实现，同时保持扩展不改旧代码——这正是 RESTful 服务、策略路由、插件化模块等场景背后的关键机制。
用接口类型定义服务入口
API 方法参数或返回值直接使用接口类型，而非具体实现类。这样调用方只依赖契约，不感知底层变化。
- 例如定义
PaymentService接口，再让WechatPayServiceImpl、AlipayServiceImpl实现它 - 控制器方法写成
public ResponseEntity<String> pay(@RequestBody Order order, PaymentService service) - 运行时传入任意实现类实例，逻辑自动适配，无需修改 controller 层
配合 Spring 的 @Qualifier 或 @Primary 灵活切换实现
Spring 容器天然支持多态注入。当多个 Bean 实现同一接口时，可通过注解精准控制使用哪个。
- 给不同支付实现类加上
@Service("wechatPay")和@Service("alipay") - 在需要的地方用
@Autowired @Qualifier("wechatPay") PaymentService service - 甚至结合配置项动态选择：
@Value("${payment.type:wechat}") String type，再用工厂模式返回对应实例
避免强转，用策略模式封装行为分支
多态下若频繁用 instanceof + 强转调用特有方法，说明设计已偏离初衷。应把差异行为提取为策略。
立即学习“Java免费学习笔记（深入）”；
- 不要写：
if (service instanceof WechatPayService) { ((WechatPayService)service).refundWithCert(...) } - 改为在
PaymentService中统一定义refund(RefundRequest req)方法，各实现类内部自行处理证书、签名等细节 - 新增支付方式时，只需新增一个实现类，不碰原有逻辑
结合泛型与通配符增强 API 兼容性
对外暴露的通用工具类或响应包装类，合理使用泛型边界可提升复用性与类型安全。
- 如定义
ApiResponse<T>，返回ApiResponse<OrderDetail>或ApiResponse<UserSummary>都合法 - 集合参数可用通配符：
public void batchProcess(List<? extends BusinessEntity> entities)，接受任何业务实体子类列表 - 避免使用
Object或原始类型，减少运行时类型错误
