Go中适配新接口的唯一可行方式是编写适配器类型：用struct包装旧类型并手动桥接方法调用，不可用嵌入、interface{}或反射；单方法接口可选函数类型适配，但需注意无状态限制。
Go 里没有接口继承，怎么让旧代码适配新接口？
Go 的接口是隐式实现的，不支持继承或泛型约束下的“向上转型”，所以不能靠改接口定义来凑合。真正能用的路只有一条：写一个新类型，包装旧类型，并在方法里手动桥接调用。
比如你有个老服务 LegacyDB 只有 GetByID(string) (map[string]interface{}, error)，但新框架要求实现 datastore.Reader 接口（含 Get(ctx, key string) (any, error)）。这时候就得写个适配器类型：
type LegacyDBAdapter struct {
db *LegacyDB
}
func (a *LegacyDBAdapter) Get(ctx context.Context, key string) (any, error) {
// 忽略 ctx（旧代码不支持上下文），只转发 key
return a.db.GetByID(key)
}
- 适配器必须显式持有被包装对象（
db *LegacyDB），不能靠嵌入——嵌入会暴露原方法，破坏封装边界 - 别试图在适配器里补全缺失能力（比如给没上下文的老函数硬塞
ctx.Done()监听），那属于重构，不是适配 - 如果旧类型方法签名和新接口差异大（比如参数顺序、错误返回位置不同），适配器里要做明确转换，别依赖“差不多能跑”
适配器该定义成 struct 还是 func？
90% 的情况选 struct。只有当目标接口只有一个方法，且逻辑极简（比如只是改个参数名），才考虑用函数类型转换。
例如：type HandlerFunc func(http.ResponseWriter, *http.Request) 是标准库里已有的函数适配器，它实现了 http.Handler 接口。你自己写时也可以这样：
立即学习“go语言免费学习笔记（深入）”；
type MyHandlerFunc func(string) error
func (f MyHandlerFunc) Serve(s string) error {
return f(s)
}
- 函数类型适配只适用于单方法接口，多方法就立刻失控
- 函数适配器无法携带状态（比如配置、连接池），而
struct可以通过字段存依赖 - 别为了“看起来简洁”把
struct强转成函数——Go 不允许直接类型断言函数到接口，得靠显式包装
为什么不能用 interface{} 或空接口做通用适配器？
因为 Go 的接口匹配是静态的：编译期检查是否实现了所有方法。用 interface{} 包住一个对象，它就只是个值，不会自动获得任何接口能力。
常见错误写法：
var x interface{} = &LegacyDB{}
// 下面这行会编译失败：x 没有 Get 方法
_ = x.(datastore.Reader)
-
interface{}是类型擦除后的容器，不是“万能接口代理” - 想让某个值满足某接口，必须让它所属的具体类型实现该接口——要么改原类型（通常不可行），要么用适配器类型包装
- 反射可以绕过编译检查，但代价是失去类型安全、性能下降、调试困难，不解决根本问题
适配器要不要导出？什么时候加测试？
如果适配器只在包内使用（比如内部模块对接老 SDK），就用小写名字（legacyDBAdapter），不导出。一旦它要被其他包调用，就必须导出，并配上最小必要文档。
适配器的测试重点不是“它长得像不像”，而是“它行为对不对”：
- 测试必须覆盖原接口所有方法，尤其是错误路径（比如传空 key 时，适配器是否正确透传错误，而不是 panic）
- 如果适配器做了参数转换（比如把
int64ID 转成string），测试里要验证转换逻辑，不能只测 happy path - 避免 mock 原始依赖——直接用真实
LegacyDB实例（哪怕是个内存 map），否则测的是“适配器能不能调用 mock”，不是“适配器能不能工作”
最常被跳过的点：适配器的生命周期管理。如果它包装了带资源的对象（如数据库连接、文件句柄），记得提供 Close() 方法并文档注明调用义务——这点没人提醒，但线上容易 leak。
