Go中Adapter常“没用上”是因为其本质是函数或类型转换层，用于桥接接口而非类适配；需检查方法签名是否完全匹配、指针接收者要求及error等类型严格性，必要时用wrapper类型或函数适配器实现。
为什么 Go 里写 Adapter 常常“没用上”？
因为 Go 没有继承，也不需要传统面向对象里的“类适配”，Adapter 在 Go 中本质是**函数或类型转换层**，用来桥接两个已有接口——不是为了“让不兼容的类兼容”，而是为了让一个已实现的类型能被另一个接口变量接收。
常见错误现象：cannot use myImpl (type *MyService) as type OtherInterface in argument to consume: *MyService does not implement OtherInterface。这时候不是加个“适配器类”，而是检查：它缺哪个方法？返回值/参数类型是否严格一致？
- Go 接口是隐式实现的，只要方法签名（名字、参数、返回值）完全匹配，就自动满足
- 注意
error和*errors.Error不等价；[]byte和io.Reader也不直接兼容 - 如果目标接口有指针接收者方法，你必须传
*T，不能传T
用 wrapper 类型做适配：什么时候必须定义新类型？
当你要把一个类型“塞进”另一个接口，但它的方法签名不完全匹配（比如参数多一个 context，或返回值多一个 error），就得靠包装类型 + 显式实现目标接口。
典型场景：把 http.HandlerFunc 适配成 chi.Router 要求的 http.Handler；或者把带 context.Context 的服务方法，适配成老式无 context 的回调接口。
立即学习“go语言免费学习笔记（深入）”；
- 不要用
type MyAdapter = ExistingType—— 这只是类型别名，不会继承方法 - 正确做法是
type MyAdapter struct { impl *RealService }，然后在该 struct 上实现目标接口方法 - 避免在 Adapter 方法里做耗时操作或重复初始化，它只是转发层
示例：
type LoggerAdapter struct {
l *zap.Logger
}
func (a *LoggerAdapter) Print(v ...interface{}) {
a.l.Info(fmt.Sprint(v...))
}这样就能把 *zap.Logger 当作 fmt.Printer 用了（前提是只用到 Print）。
函数适配器：比 struct wrapper 更轻量的选择
如果目标接口只有一个方法（比如 io.Writer.Write、http.Handler.ServeHTTP），直接用函数转接口更干净。
Go 标准库大量使用这种模式：http.HandlerFunc 就是把普通函数转成 http.Handler 的适配器。
- 定义：
type HandlerFunc func(http.ResponseWriter, *http.Request)，然后实现ServeHTTP方法调用自身 - 使用：
http.Handle("/path", HandlerFunc(myHandler))，无需额外 struct - 注意：函数适配器无法携带状态，要闭包捕获变量时得小心生命周期（比如引用了局部 slice 或 map）
接口嵌套 vs Adapter：别混淆“组合”和“适配”
有人把 type MyServer interface { io.Reader; io.Writer } 当作 Adapter，其实这是接口嵌套，不是适配。它不解决“已有类型不满足接口”的问题，只是定义新契约。
真正需要 Adapter 的时刻，是已有代码（比如第三方库返回的 *sql.DB）和你的抽象层（比如自定义的 DataStore 接口）之间存在方法不一致。
- 嵌套接口适合定义能力集合，Adapter 适合连接已有实现与新契约
- 如果
DataStore多了个BeginTx()，而*sql.DB有Begin()，那就得写 Adapter 包装Begin()并返回符合你事务接口的对象 - 容易被忽略的点：Adapter 返回的新对象，其方法是否也需满足同样的接口约束？比如事务对象本身也要实现
DataStore吗？这会影响设计深度
