go中写适配器是为解决已有接口间调用不匹配的硬性问题，如*http.client与doer接口不兼容，或方法名/签名差异；必须严格匹配方法签名，嵌入+覆盖可简化实现，单方法接口优先用函数适配器。
Go 里写适配器，不是为了“模拟类继承”，而是为了解决两个已有接口之间调用不上的硬问题——比如你手上有 *http.Client，但下游函数只接受 Doer 接口；或者第三方日志库的 LogInfo(string) 方法，和你定义的 Logger.Info(string) 名字/签名差了一点。这时候加个适配器，不是设计选择，是编译器逼你做的。
为什么 *MyType 传不进 SomeInterface？先看方法签名是否真匹配
常见错误信息：cannot use myImpl (type *MyService) as type OtherInterface in argument to consume: *MyService does not implement OtherInterface。这不是语法错误，是 Go 编译器在告诉你：它比对了所有方法，发现至少一个不一致。
- 方法名大小写必须完全一样（
Info≠info） - 参数类型不能“差不多”——
int和int64不兼容，error和*errors.Error也不等价 - 返回值顺序、数量、类型必须严格一致；多一个
error或少一个context.Context都不行 - 如果原类型方法用的是指针接收者（如
func (s *Service) Do()），那你必须传*Service，不能传Service值类型
用嵌入 + 方法覆盖，比从头写 struct wrapper 更省事
当你发现目标接口只比原类型多一两个方法，或仅参数名/顺序不同，别逐个重写全部方法。直接嵌入原类型，再只覆盖差异部分即可：
type LegacyAPI struct{}<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 }</em></code><code>func (a APIAdapter) Fetch(url string) ([]byte, error) {</code><code> s, err := a.Get(url)</code><code> return []byte(s), err</code><code>}</code></p>
注意：*LegacyAPI 是指针嵌入，这样能透传所有指针接收者方法；如果嵌入的是 LegacyAPI（值类型），且其方法全是 (*T).M，那嵌入后无法自动提升。
单方法接口优先用函数适配器，别套 struct
像 http.Handler、io.Writer、fmt.Stringer 这类只有一个方法的接口，函数转接口最干净：
type HandlerFunc func(http.ResponseWriter, *http.Request)<code>func (f HandlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w, r) }</code><p><code>// 直接用，无需定义新 struct</code><code>http.Handle("/ping", HandlerFunc(func(w http.ResponseWriter, r *http.Request) {</code><code> w.Write([]byte("ok"))</code><code>}))</code></p>
这种模式在标准库中大量存在，轻量、易测、无额外内存分配。只有当需要携带状态（比如带配置的 logger）、或目标接口有多个方法时，才考虑 struct wrapper。
空指针、context 丢失、error 包装——三个地方最容易漏检查
适配器不是透明管道，它是一层显式转换逻辑。这三个坑在压测或上线后才暴露：
- 嵌入字段为 nil 时直接 panic：在构造函数里加校验，比如
if src == nil { panic("nil adaptee") } - 原接口支持
context.Context，目标接口没暴露——别默默丢掉，要么用context.Background()显式降级，要么把 context 提到参数里（需上下游协同） - 错误未包装就返回：原方法返回
errors.New("timeout")，你直接return nil, err没问题；但如果要加 trace ID 或统一错误码，得用fmt.Errorf("fetch failed: %w", err)包装，否则调用方的错误断言会失败
真正难的不是写适配器，是判断该不该写——有时候改调用方接口、或让被适配方升级，比套一层 wrapper 更可持续。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
