一、接口适配基础：什么是接口适配、为什么需要适配层、适配器模式原理、接口适配的层次划分

1.1 什么是接口适配？说白了就是「翻译官」

接口适配这个概念，我刚开始接触时也觉得挺玄乎。后来做了几个项目才明白——接口适配，就是让两个原本不兼容的系统能正常对话。

你想想看，现实世界里，美标插头插不进国标插座，怎么办？加个转换头。接口适配干的就是这个活。

在软件系统里，情况更复杂一些。A系统返回的是XML格式，B系统只认JSON。A系统用HTTP/1.1，B系统强制要求gRPC。这时候如果没有适配层，两个系统就像鸡同鸭讲，根本没法合作。

我个人习惯把接口适配分成两类：

• 协议适配：比如HTTP转gRPC、WebSocket转MQTT
• 数据适配：比如XML转JSON、字段名映射、类型转换

我记得有一次做物联网项目，设备端用的是私有二进制协议，后端服务只认标准MQTT。没有适配层的话，要么改设备固件，要么改后端代码——两边都动，成本太高。最后我们加了一层协议适配器，问题就解决了。

1.2 为什么需要适配层？血的教训告诉我

很多新手会问：为什么不直接改代码，非要加一层？

嗯，这个问题我当年也问过。直到有一次，我接手一个老系统改造项目。原系统对接了7个第三方支付渠道，每个渠道的接口格式都不一样。代码里到处都是if-else判断，一个接口改动，要改十几个地方。那代码，说实话，看着就头疼。

适配层的核心价值，我总结为三点：

价值点	说明	我遇到的真实案例
解耦	调用方不关心被调用方的实现细节	支付渠道从支付宝换成，业务代码一行没改
复用	一套适配逻辑可以被多个调用方共享	三个业务线共用同一个短信适配器
隔离变化	外部接口变化时，只改适配层	第三方API升级v2，只动了适配器里的两行代码

1.3 适配器模式原理：GoF经典设计模式

说到接口适配，绕不开适配器模式。这是GoF 23种设计模式之一，也是我工作中用得最多的模式之一。

适配器模式的核心思想：将一个类的接口转换成客户希望的另一个接口。

说白了，就是「包装」一下。你有一个老接口，新系统不认，那就包一层新皮，让老接口看起来像新接口。

我画了一张图，帮你理解适配器模式的结构：

看明白了吗？客户端只认识Target接口，适配器实现了Target接口，同时持有Adaptee的引用。客户端调用Request()，适配器内部转调Adaptee的SpecificRequest()。

来个代码示例，更直观：

// 老接口 - 第三方短信服务
public class OldSmsService {
    public void sendText(String phone, String msg) {
        // 老逻辑：只支持纯文本
        System.out.println("发送短信到 " + phone + ": " + msg);
    }
}

// 新接口 - 我们系统期望的
public interface INewSmsService {
    void sendSms(String phone, String content, String format);
}

// 适配器
public class SmsAdapter implements INewSmsService {
    private OldSmsService oldService;
    
    public SmsAdapter(OldSmsService oldService) {
        this.oldService = oldService;
    }
    
    @Override
    public void sendSms(String phone, String content, String format) {
        // 适配逻辑：忽略format，只提取纯文本
        String plainText = stripHtml(content);
        oldService.sendText(phone, plainText);
    }
    
    private String stripHtml(String html) {
        return html.replaceAll("<[^>]*>", "");
    }
}

1.4 接口适配的层次划分：从底层到顶层

接口适配不是一锤子买卖。在实际项目中，适配发生在不同层次。我习惯把它分成四个层次：

第一层：协议适配

这是最底层的适配。两个系统用的通信协议不一样，比如一个用HTTP，一个用gRPC。这时候需要协议网关来做转换。

我在做微服务迁移时遇到过：旧服务暴露的是RESTful API，新服务要求gRPC。我们在网关层加了一个协议适配器，把HTTP请求转成gRPC调用，业务代码一行没改。

第二层：数据格式适配

协议通了，但数据格式不匹配。比如A系统返回JSON，B系统只认XML。或者字段名不一样——A系统叫userId，B系统叫user_id。

这种适配通常用映射表解决。我建议把映射关系配置化，不要硬编码。这样改映射时不用重新部署。

第三层：接口语义适配

这个层次比较微妙。两个接口功能相同，但语义不同。比如A系统的「创建订单」接口是同步的，B系统要求异步——先提交，再轮询结果。

语义适配需要理解业务逻辑，不能简单做字段映射。我一般会写一个「编排适配器」，把多个调用组合成一个完整流程。

第四层：业务逻辑适配

这是最高层次的适配。两个系统的业务流程不同，但最终目标一致。比如A系统下单后直接扣库存，B系统下单后先锁定库存，支付成功再扣减。

这种适配最复杂，需要深入理解业务。我建议把业务适配和接口适配分开，不要让适配器承担太多业务逻辑。

层次	适配内容	复杂度	典型工具/模式
协议适配	HTTP/gRPC/MQTT/WebSocket	低	API网关、协议转换器
数据格式适配	JSON/XML/Protobuf/字段映射	中	Jackson、MapStruct、配置映射表
接口语义适配	同步/异步、请求/响应模式	中高	编排适配器、消息队列
业务逻辑适配	业务流程差异、状态机转换	高	策略模式、状态模式

好了，接口适配的基础就讲到这里。记住一句话：适配层是系统的「减震器」，不是「垃圾堆」。保持它轻量、专注、可配置，你的系统会感谢你的。