适配器解决的是已有接口不匹配问题，通过结构体嵌入和方法委托实现轻量适配，避免手动实现全部方法；需注意空指针校验、context传递与错误包装，并将超时重试等逻辑剥离至调用方或中间件。
适配器要解决的不是“写代码”，而是“已有接口不匹配”
Go 里没有传统 OOP 的继承和抽象类，所谓适配器模式，本质是用结构体字段 + 方法委托，把一个类型“包一层”，让它满足另一个接口。关键不在设计图，而在你手上已经有两个不兼容的接口，又不能改对方代码——比如调用第三方 SDK 的 Client.Do()，但你的业务逻辑只认 Fetcher.Fetch()。
用嵌入+方法重定向是最轻量的适配方式
别写空壳 struct 再手动实现所有方法。直接嵌入原类型，再覆盖冲突或缺失的方法即可。Go 的匿名字段天然支持字段和方法提升，省掉大量胶水代码。
- 如果目标接口只比原类型多一个方法，就只实现那一个，其余自动透传
- 如果签名不一致（比如参数名不同、返回 error 位置不同），必须显式写方法体做转换
- 避免在适配器方法里做耗时操作（如加锁、IO），这会让调用方误判性能边界
type LegacyAPI struct{}</code><code>func (l *LegacyAPI) Get(url string) (string, error) { /* ... */ }</code><p><code>type Fetcher interface { Fetch(string) ([]byte, error) }</code></p><p><code>type APIAdapter struct{ <em>LegacyAPI }</code><code>func (a </em>APIAdapter) Fetch(url string) ([]byte, error) {</code><code> s, err := a.Get(url)</code><code> return []byte(s), err</code><code>}立即学习“go语言免费学习笔记（深入）”；
当涉及多个源类型时，别堆 if-else，用注册表+工厂
硬编码判断类型再 new 对应适配器，会随新来源增加迅速腐化。用 map[string]func() Fetcher 注册构造函数，运行时查表创建实例更可控。
- 注册键建议用配置名或 provider ID（如
"aws-s3"、"minio"），别用类型名，否则耦合反射 - 工厂函数返回接口，内部 new 具体适配器，隐藏实现细节
- 注意并发安全：map 默认非线程安全，初始化阶段完成注册，运行时只读即可
容易被忽略的坑：空指针、context 传递、错误包装
适配器不是透明管道。三个地方最容易出错：
- 嵌入字段为 nil 时调用方法 panic —— 在适配器构造函数里强制校验
if src == nil { panic("nil source") } - 原接口支持
context.Context，但目标接口没暴露 —— 别丢 context，要么在适配器里用context.Background()（明确降级），要么扩展目标接口（需上下游协同） - 错误直接 return 原始 error，丢失上下文 —— 用
fmt.Errorf("fetch from legacy: %w", err)包装，保留原始栈和因果链
适配器越薄越好，但薄不等于偷懒。真正难的是厘清谁该负责超时、重试、日志——这些不该塞进适配层，而应在调用方或中间件里统一处理。
