根本原因是go接口要求方法签名完全匹配，包括参数个数、类型、顺序及返回值；参数多一个或少一个即导致cannot use xxx as type yyy错误。
接口方法参数个数不一致时，为什么直接赋值会报错
错误信息通常是 cannot use xxx as type YYY。根本原因不是“参数多一个少一个”，而是 Go 接口要求方法签名（包括参数个数、类型、顺序、返回值）必须完全匹配。哪怕目标接口方法是 Do(a, b int)，而你手上的函数是 do(a int) 或 do(a, b, c int)，编译器就拒绝隐式转换——它不帮你删参、补参或重排。
用函数类型适配单方法接口：最轻量的解法
当目标接口只含一个方法，且你有多个参数个数/类型不同的函数要塞进去，优先考虑函数类型转换。标准库的 http.HandlerFunc 就是典型：
type HandlerFunc func(http.ResponseWriter, *http.Request)
func (f HandlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) {
f(w, r)
}
这样你就能把任意符合 func(http.ResponseWriter, *http.Request) 签名的函数转成 http.Handler：
-
http.Handle("/a", HandlerFunc(handlerA))—— handlerA 必须是两参数 - 若你有个三参数函数
handlerB(w, r, extra string)，不能直接转；得包装：HandlerFunc(func(w, r) { handlerB(w, r, "fixed") }) - 若只有单参数函数
logMsg(msg string)，也得闭包补全：HandlerFunc(func(w, r) { logMsg("request arrived") })
用 struct wrapper 适配多方法或签名差异大的接口
当接口有多个方法，或参数差异无法靠闭包简单补全（比如类型不兼容、需 context 透传、error 包装），就得定义结构体显式实现：
- 别用
type MyAdapter = ExistingType—— 这只是别名，不继承方法 - 正确做法是
type MyAdapter struct { impl SomeService }，然后在MyAdapter上实现目标接口全部方法 - 如果原类型已实现部分方法，可匿名嵌入：
type MyAdapter struct { *SomeService }，但构造时必须确保impl != nil，否则调用时 panic - 参数不匹配的地方手动转换：比如目标接口要
Get(ctx context.Context, key string) ([]byte, error)，而原服务只有Get(key string) ([]byte, error)，就在 wrapper 里写func (a *MyAdapter) Get(ctx context.Context, key string) ([]byte, error) { return a.impl.Get(key) }
可变参数函数包装时的解包陷阱
当你想把 fmt.Printf 这类可变参数函数适配进某个日志接口，常见错误是把 []interface{} 直接传过去：
func badLog(format string, args interface{}) {
fmt.Printf(format, args) // 错！args 是 []interface{}，printf 当作单个参数
}
func goodLog(format string, args ...interface{}) {
fmt.Printf(format, args...) // 对！用 ... 解包
}
- 接收方必须声明为
...interface{}，否则无法承接任意数量参数 - 转发时必须用
args...，否则fmt.Printf收到的是一个切片，不是展开的参数列表 - 如果目标接口方法签名固定（如
Log(msg string, fields map[string]interface{})），那就别硬套可变参数，老实用结构体封装
真正难的不是写 wrapper，而是判断该用函数闭包还是 struct：前者干净但无状态，后者灵活但要管空指针和 context 传递。多数人卡在第一步——没看清接口方法签名到底差在哪，就急着写 struct，结果白忙活。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
