go中适配器模式核心是组合+接口隐式实现：用结构体字段持有旧对象并手动实现目标接口，避免继承；函数适配器更轻量，通过类型别名绑定方法；嵌入需谨慎以防暴露多余方法；须做nil检查、统一接收者类型、不掺业务逻辑。
Go 里实现适配器模式，核心就一条：不改旧代码，靠组合+接口隐式实现把不匹配的类型“接上”新接口。 它不是继承重写，而是用结构体字段持有旧对象，再手动实现目标接口方法——编译能过、逻辑干净、替换方便。
怎么写一个最常用的结构体适配器
当已有类型 LegacyLogger 只有 LogError(msg String)，但业务要传 Logger 接口（要求 Log(level, msg string)），就得写适配器：
- 定义新结构体，显式持有旧类型指针（
*LegacyLogger），避免嵌入带来的意外方法暴露 - 为该结构体实现
Logger.Log方法，在内部做参数映射和转发 - 返回值、错误处理必须严格对齐目标接口，不能漏
error或错类型
type LegacyLoggerAdapter struct { logger *LegacyLogger } func (a *LegacyLoggerAdapter) Log(level string, msg string) { switch level { case "error": a.logger.LogError(msg) default: fmt.Printf("[%s] %sn", strings.ToUpper(level), msg) } }函数也能当适配器：别硬套结构体
当被适配的是独立函数（比如 sendEmail(string) error），而你需要满足 io.Writer 接口，结构体就太重了——直接用类型别名+方法绑定更轻量：
- 定义类型别名
type EmailWriter func(string) error - 给它实现
Write([]byte) (int, error)方法，内部调用原函数并做[]byte → string转换 - 初始化时传闭包，而不是新建结构体实例，减少内存分配
type EmailWriter func(string) error func (e EmailWriter) Write(p []byte) (int, error) { err := e(string(p)) return len(p), err } writer := EmailWriter(sendEmail) io.WriteString(writer, "alert!")嵌入（embedding）什么时候能用、什么时候要躲
嵌入 *LegacyLogger 看似省事，但容易踩坑：
- 嵌入后，
LegacyLogger的所有导出方法（如Close()、SetLevel()）自动变成适配器的方法，可能破坏接口契约 - 如果目标接口只要
Log()，但用户误调adapter.Close()，行为不可控 - 仅在旧类型方法语义完全一致、且你明确想暴露全部能力时才考虑嵌入；否则一律用显式字段 + 手动委托
适配器里最容易忽略的三件事
适配器不是翻译腔，它得稳得住：
-
nil检查必须做：适配器字段如果是*LegacyLogger，方法里第一行就要if a.logger == nil { panic("...") }或返回错误 - 接收者类型要统一：如果旧方法是值接收者，适配器内调用也别用指针；反之亦然，否则可能触发拷贝或 panic
- 别掺业务逻辑：过滤日志级别、拼接 URL、加重试——这些不是适配器的职责，应该交给上层或中间件
真正难的不是写出来，而是判断“这里该不该加一层适配”。多数时候，当你看到类型不匹配又不能改对方代码，那就是适配器该出场的时候了。