Go适配器模式通过组合与接口转换实现，而非继承；适用于无法修改第三方/遗留代码但需匹配自定义接口的场景，核心是包装行为、转换接口形状。
Go 语言没有接口继承和类继承，所以适配器模式不是靠「让类实现某接口」来硬套，而是靠组合 + 接口转换来达成目标。核心在于：把一个已有类型的行为，包装成另一个接口所期望的形状。
什么时候该用 Adapter 而不是直接改原类型
常见于对接第三方库、遗留代码或标准库时——你无法修改对方源码，但又需要它符合你当前系统定义的接口。比如：
- 标准库的
http.ResponseWriter不满足你自定义的Writer接口（比如多了StatusCode()方法） - 某个 SDK 返回的
DBClient只有Exec()和Query()，而你的业务层依赖的是DataStore接口（含BeginTx(),Close()） - 测试中想把
*bytes.Buffer当作实现了io.ReadCloser的对象用，但它没实现Close()
最简适配器：嵌入 + 方法转发
这是最轻量、最 Go 风格的做法。不新增结构体字段，只通过嵌入已有类型，并补全缺失方法：
// 假设你有这个接口
type DataWriter interface {
Write(data []byte) error
Close() error
}
// 第三方类型（你不能改）
type LegacyWriter struct{}
func (l *LegacyWriter) Write(data []byte) error {
// 实际写逻辑
return nil
}
// 适配器：嵌入 + 补 Close
type LegacyWriterAdapter struct {
*LegacyWriter
}
func (a *LegacyWriterAdapter) Close() error {
// 可以是空实现、日志、资源清理等
return nil
}
注意：*LegacyWriterAdapter 现在能赋值给 DataWriter 接口变量。这种写法干净、零分配、无中间层开销。
立即学习“go语言免费学习笔记（深入）”；
带状态的适配器：显式字段 + 组合
当适配逻辑需要额外状态（如缓存、配置、上下文），就不能只靠嵌入了。必须显式持有被适配对象，并手动实现所有接口方法：
type LoggingDBAdapter struct {
db *sql.DB
logger *log.Logger
}
func (a *LoggingDBAdapter) Query(query string, args ...interface{}) ([]map[string]interface{}, error) {
a.logger.Printf("QUERY: %s", query)
// 转调 db.QueryContext 或其他逻辑
return nil, nil
}
func (a *LoggingDBAdapter) Exec(query string, args ...interface{}) (int64, error) {
a.logger.Printf("EXEC: %s", query)
return 0, nil
}
关键点：
- 不要试图让
LoggingDBAdapter嵌入*sql.DB—— 它不是 DB，只是“用 DB 做事的代理” - 方法名不必和原类型一致（
QueryvsQueryRow），只要满足目标接口签名即可 - 如果原类型方法返回值与目标接口不兼容（比如多一个
error），适配器里要处理掉或转换
容易踩的坑：空指针、循环引用、接口零值
适配器本质是包装，出错往往发生在初始化或调用链路中：
- 忘记初始化嵌入字段：
ad := &LegacyWriterAdapter{}中LegacyWriter是 nil，调Write()panic - 在适配器方法里误调自己（而非被包装对象），造成无限递归 —— 尤其在重名方法中
- 把适配器当成可导出类型到处传，结果接收方做了类型断言（
v, ok := w.(*LegacyWriterAdapter)），这破坏了接口抽象，也限制复用 - 适配器内部缓存了旧状态（如连接、token），但没提供
Reset()或Refresh()，导致后续调用行为异常
真正难的从来不是“怎么写一个适配器”，而是判断“该不该在这里加一层适配”——多数时候，重构原接口或换用更小粒度的组合，比硬套模式更可持续。
