适配器模式通过创建适配器结构体将第三方支付接口MakePayment转换为系统统一的Pay接口，使不兼容的接口能够协同工作。1. 定义Payment接口规范；2. 第三方服务ThirdPartyPay提供MakePayment方法；3. ThirdPartyPayAdapter组合ThirdPartyPay并实现Pay方法，完成参数转换与调用封装；4. 业务流程通过Payment接口调用，无需感知底层差异。更换支付服务时只需新增适配器，原有逻辑不变，实现解耦。Go语言利用接口隐式实现和结构体组合特性，简洁高效地支持适配器模式，提升系统扩展性与可维护性。
在Go语言开发中，经常会遇到两个模块或服务之间接口不匹配的情况。比如你正在集成一个第三方支付SDK，它的接口返回的是XML格式数据，而你的系统内部统一使用JSON结构体处理订单信息。这时候直接调用会导致类型不兼容、方法无法对接等问题。适配器模式正是为了解决这类“接口不兼容”的典型设计模式。
适配器模式的核心思想
适配器模式通过引入一个中间层——适配器，将一个类的接口转换成客户端期望的另一个接口。它不需要修改原有代码，也不要求第三方组件重构接口，就能让原本不能一起工作的对象协同运作。
在Golang中，由于没有继承机制，我们主要依赖组合和接口实现来达成适配目的。
场景模拟：支付系统接口适配
假设我们的业务系统定义了一个统一的支付接口：
立即学习“go语言免费学习笔记（深入）”；
type Payment interface {
Pay(amount float64) error
}
但我们接入的第三方支付服务商提供的结构体却是这样的：
type ThirdPartyPay struct{}
func (t *ThirdPartyPay) MakePayment(value int) string {
return fmt.Sprintf("Paid %d successfully", value)
}
可以看到，原生方法叫 MakePayment，参数是 int 类型，返回值是字符串，与我们系统的 Pay(float64) 完全不匹配。
编写适配器进行接口转换
我们需要创建一个适配器，让它实现我们的 Payment 接口，同时内部调用第三方服务。
type ThirdPartyPayAdapter struct {
service *ThirdPartyPay
}
func (a *ThirdPartyPayAdapter) Pay(amount float64) error {
// 转换 float64 -> int
intValue := int(amount)
result := a.service.MakePayment(intValue)
// 简单判断是否成功（可根据实际逻辑增强）
if strings.Contains(result, "successfully") {
return nil
}
return errors.New("payment failed")
}
这样，外部系统就可以通过标准的 Payment 接口调用，无需关心底层具体实现。
使用适配器完成解耦
现在可以在主流程中安全地使用适配后的服务：
func ProcessOrder(payment Payment, amount float64) {
err := payment.Pay(amount)
if err != nil {
log.Printf("Payment failed: %v", err)
return
}
log.Println("Payment succeeded")
}
// 使用示例
thirdParty := &ThirdPartyPay{}
adapter := &ThirdPartyPayAdapter{service: thirdParty}
ProcessOrder(adapter, 99.9)
如果未来更换为支付宝或微信支付，只需新增对应的适配器并实现 Payment 接口，原有业务逻辑完全不用改动。
基本上就这些。适配器模式的关键在于隔离变化，提升系统的扩展性和可维护性。在Go中利用接口隐式实现和结构体组合，能非常简洁地完成接口适配，避免因外部依赖变更导致的大范围代码调整。对于需要集成多个异构服务的项目来说，这是一种实用且优雅的解决方案。
