Go接口是“满足”而非“实现”，类型只需拥有接口全部方法签名即自动满足，无需显式声明；接收者类型必须严格一致，空接口可存任意类型但需断言使用，接口变量nil判断需同时考虑动态类型和值。
Go 接口不是“实现”，是“满足”
Go 里没有“继承接口”或“implements 关键字”，接口的多态不靠声明，而靠结构体字段和方法签名是否恰好匹配。只要一个类型有接口要求的所有方法（名称、参数、返回值完全一致），它就自动满足该接口——不需要显式声明。
常见错误现象：cannot use xxx (type *MyStruct) as type MyInterface in argument，往往是因为方法接收者类型不一致（比如接口要求 func (m MyStruct) Do()，你写了 func (m *MyStruct) Do()，或反过来）。
- 接收者类型必须严格一致：值接收者满足值接收者接口，指针接收者满足指针接收者接口；
*T可以调用T的值接收者方法，但接口约束看的是**方法集定义时的接收者** - 空接口
interface{}是所有类型的超集，但没方法，无法直接调用行为——要类型断言或反射才能用 - 接口变量本身只存两部分：动态类型（具体类型） + 动态值（实例），底层无虚函数表，开销极小
如何安全做类型断言并避免 panic
用 value, ok := iface.(ConcreteType) 形式判断接口变量是否为某具体类型，比强制断言 value := iface.(ConcreteType) 更健壮——后者在不匹配时直接 panic。
使用场景：处理 HTTP handler 中不同请求体结构、解析 JSON 后根据字段动态分发逻辑、插件系统中加载未知类型组件。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 断言失败时
ok为false，value是目标类型的零值，不会 panic - 嵌套断言要小心：先断言外层接口，再对内部值做二次断言，别链式写成
iface.(*A).(*B) - 如果断言后需多次使用该值，建议先赋给局部变量，避免重复断言（Go 不会缓存断言结果）
- 错误信息如
panic: interface conversion: interface {} is int, not string就是强制断言失败的典型提示
接口嵌套与组合的实际写法
Go 接口支持嵌套，本质是字段展开，不是继承。把多个小接口组合成大接口，能提升复用性，也更符合单一职责。
例如 io.ReadWriter 就是 io.Reader 和 io.Writer 的嵌套：
type ReadWriter interface {
Reader
Writer
}
这等价于手动列出 Read 和 Write 方法。但嵌套让意图更清晰，也方便后续扩展（比如加个 io.Closer 进去）。
- 嵌套接口不能有重名方法，否则编译报错：
duplicate method XXX - 嵌套后，实现方只需实现所有被展开的方法，不用管嵌套层级
- 不要为了“看起来像类”而过度嵌套；接口越小、越正交，越容易被复用和测试
- 标准库中大量使用这种模式：
http.ResponseWriter嵌套了io.Writer，所以你能直接传给json.NewEncoder
为什么有时候接口变量 nil，但底层值不为 nil
这是 Go 接口最常被忽略的坑：接口变量本身是 nil，仅当其动态类型和动态值都为 nil 时才成立。如果类型非空、值为 nil 指针（比如 *MyStruct(nil)），接口变量就不等于 nil。
典型错误现象：函数返回 MyInterface，内部 new 了一个结构体但忘了初始化字段，调用方法时 panic：invalid memory address or nil pointer dereference，但 if myIface == nil 却不进分支。
- 判断接口是否“真正可用”，不能只比
== nil，得结合具体业务逻辑——比如检查其方法返回值是否有效 - 构造返回接口的函数时，明确约定：返回
nil表示“无实例”，还是允许返回“有效类型 + nil 值” - 单元测试里务必覆盖
nil指针实现的接口调用路径，否则上线后容易静默崩溃
