Go中适配器模式通过组合+接口隐式实现：用结构体字段持有被适配对象，手动实现目标接口方法并委托调用；不依赖继承，关键在于隐式满足接口契约。
适配器模式在 Go 里没有接口继承，怎么写？
Go 没有传统 OOP 的「类继承」和「接口继承」，所以不能像 Java 那样让适配器类 extends Target implements Adaptee。它的适配器本质是「组合 + 接口隐式实现」：用一个字段持有被适配对象，再通过结构体方法满足目标接口。
关键点在于：Go 接口是隐式实现的，只要结构体提供了接口要求的所有方法签名，就自动实
现了该接口——不需要 implements 声明。
- 适配器结构体里嵌入或持有原对象（
Adaptee），不继承，只组合 - 适配器自己实现目标接口（
Target）的方法，内部转发/转换调用原对象 - 如果原对象已有部分匹配方法，可直接嵌入提升（
type Adapter struct { *Adaptee }），但要注意方法名冲突和语义一致性
写一个文件读取器适配器：把 os.File 适配成自定义 Reader 接口
常见场景：已有 *os.File，但下游只接受你定义的 MyReader 接口，而它比 io.Reader 多一个 Path() 方法。这时就得写适配器桥接。
注意：别试图让 *os.File 直接实现 MyReader（无法修改标准库类型），而是封装一层。
type MyReader interface {
Read(p []byte) (n int, err error)
Path() string
}
type FileReaderAdapter struct {
file *os.File
path string
}
func NewFileReaderAdapter(f *os.File, path string) *FileReaderAdapter {
return &FileReaderAdapter{file: f, path: path}
}
func (a *FileReaderAdapter) Read(p []byte) (int, error) {
return a.file.Read(p) // 直接委托
}
func (a *FileReaderAdapter) Path() string {
return a.path // 补充原类型没有的信息
}
这样下游就能安全传入 *FileReaderAdapter，完全满足 MyReader 接口，且不侵入原有逻辑。
什么时候该用嵌入（embedding）而不是显式字段？
当被适配对象的大部分方法你都想直接暴露，仅需调整少数几个时，嵌入更简洁；但必须小心「方法提升带来的意外行为」。
- 嵌入
*Adaptee后，所有公开方法自动成为适配器的方法——包括你不希望暴露的（比如Close()） - 如果目标接口只要求
Read()，但嵌入后用户还能调Write()，就破坏了接口契约 - 若只是轻量转换（如改返回值、加日志、转编码），推荐显式字段 + 手动委托，控制力更强
例如，适配一个返回 error 的旧函数为返回 *MyError 的新接口，就不能靠嵌入，必须手动包装：
func (a *LegacyAdapter) Do() *MyError {
if err := a.legacy.Do(); err != nil {
return &MyError{Msg: err.Error()}
}
return nil
}
容易踩的坑：空指针、生命周期和接口零值
适配器本身是普通结构体，如果字段没初始化就调用方法，会 panic；另外 Go 接口变量可为 nil，但调用其方法不一定 panic——取决于底层具体类型是否允许 nil 接收者。
-
var r MyReader是 nil 接口，此时r.Read(...)会 panic：「nil pointer dereference」（如果底层是*FileReaderAdapter且方法接收者是指针） - 构造函数（如
NewXXXAdapter）必须校验依赖是否非 nil，尤其对*os.File这类资源句柄 - 不要在适配器里缓存不可复用的状态（如已关闭的
file），否则后续调用会失败
最稳妥的做法：所有适配器方法都做前置检查，或依赖构造函数保证字段有效性。
适配器模式在 Go 里不是语法糖，而是明确的组合意图表达。真正难的不是写法，是判断「哪里真的需要适配」——很多情况下，直接重构调用方接口，比套一层适配器更干净。
