适配器模式统一API接口，门面模式简化复杂调用，策略模式支持多供应商切换，装饰器模式增强功能；通过封装解耦外部依赖，提升代码可维护性与扩展性。
封装复杂的第三方API调用时，设计模式能显著提升代码的可维护性、可测试性和扩展性。关键在于解耦业务逻辑与外部依赖，隐藏实现细节，并提供清晰的接口。以下是几种常用设计模式及其应用场景。
1. 适配器模式：统一不一致的API接口
第三方API的接口可能命名混乱、参数结构不一致或返回格式多变。使用适配器模式可以将这些差异封装起来，对外暴露统一的接口。
做法是创建一个中间层类，该类实现项目内部定义的标准接口，内部调用第三方API并处理数据转换。
- 定义一个通用响应结构，如ApiResponse
- 编写适配器类，将第三方返回的JSON或XML映射为内部DTO
- 在适配器中处理字段重命名、缺失值默认填充等逻辑
这样上层业务无需关心不同API的具体差异，只需调用适配后的标准方法。
2. 门面模式：简化复杂调用流程
某些第三方服务需要多个步骤才能完成一个操作（如认证、初始化、上传、确认），门面模式可以把这一系列调用封装成一个简单方法。
比如上传文件到云存储，可能涉及获取token、分片上传、合并文件、生成链接等多个步骤。通过门面类暴露一个uploadFile()方法即可完成全部流程。
- 隐藏底层调用顺序和依赖关系
- 减少客户端代码的复杂度
- 便于后续替换实现而不影响调用方
3. 策略模式：支持多种API提供商切换
当系统需要对接多个同类服务商（如短信平台有阿里云、腾讯云等），策略模式可以让切换变得灵活。
定义一个公共接口，每个服务商实现自己的调用逻辑，运行时根据配置选择具体策略。
- 避免大量if-else判断供应商类型
- 新增供应商只需添加新类，符合开闭原则
- 结合工厂模式动态创建实例更简洁
4. 装饰器模式：增强功能而不动原逻辑
在不修改原有调用代码的前提下，为API添加日志记录、缓存、重试机制等功能。
例如，创建一个带重试功能的装饰器，在网络不稳定时自动重发请求；或添加缓存装饰器，避免频繁调用消耗额度。
- 职责分离，核心调用与附加行为解耦
- 可组合多个装饰器实现复合功能
- 适合横切关注点（cross-cutting concerns）
基本上就这些。合理组合这些模式，能把混乱的第三方API变成稳定可控的内部服务。关键是先抽象出业务需要的能力，再决定如何封装外部依赖。不要让外部变化穿透到核心逻辑里。
