Go 接口不是类型约束，是行为契约

Go 的 interface{} 不是 Java/C# 那种“必须显式实现”的接口。它不关心你是什么类型，只看你有没有提供对应方法签名。只要结构体、指针、甚至函数类型实现了所有接口方法，就自动满足该接口——没声明、没继承、没 implements 关键字。

常见错误是写完一个结构体后，还去加一句 var _ MyInterface = (*MyStruct)(nil) 来“强制检查”，这其实只是编译期断言，不是必需步骤。真正该做的是：先定义接口（比如 Reader），再让具体类型自然满足它。

• 接口越小越好，io.Reader 就只有 Read([]byte) (int, error) 一个方法
• 避免提前抽象：别为了“看起来解耦”而先写一堆空接口，等真有 2 个以上实现再提炼
• 值接收者 vs 指针接收者影响接口满足性：如果接口方法用指针接收者，那只有 *T 能满足，T 值类型不行

用空接口 interface{} 时，别忘了类型断言和反射开销

interface{} 是万能容器，但不是万能解药。它把类型信息擦除了，想拿回来就得靠类型断言（v, ok := x.(string)）或 reflect 包。一旦频繁做这个动作，性能会掉，代码也容易崩。

典型场景是写通用日志函数、配置解析器或 JSON 反序列化后的字段访问。这时候要注意：

• 类型断言失败返回零值 + false，不加 ok 判断直接用会 panic，错误信息是 panic: interface conversion: interface {} is int, not string
• 嵌套 map[string]interface{} 解析 JSON 后，每层取值都要断言，建议尽早转成结构体（json.Unmarshal 直接到 struct）
• fmt.Printf("%v", x) 内部用了反射，对大对象或深度嵌套结构体较慢，生产环境慎用于高频日志

接口嵌套不是继承，是组合行为

Go 接口支持嵌套，比如 type ReadWriter interface { Reader; Writer }，但这不是面向对象里的“子类继承父类”，只是语法糖，等价于把 Reader 和 Writer 的所有方法平铺进来。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

实际用的时候容易踩坑：

• 嵌套接口不会带来任何运行时开销，但会让接口膨胀。别为了“复用”把无关方法塞进一个大接口里
• 两个接口嵌套了同名方法（如都含 Close() error），没问题；但如果签名不同（比如参数个数或类型不一致），编译直接报错：duplicate method Close
• 嵌套不传递实现：即使 A 实现了 Reader，B 嵌套了 Reader，A 也不会自动满足 B —— 满足关系只看方法集，不看嵌套路径

测试 mock 接口时，别手动写大段 fake 实现

写单元测试要 mock 依赖（比如数据库、HTTP 客户端），最直接方式是让 fake 类型实现接口。但手写 func (f *FakeDB) Query(...) { ... } 很累，尤其接口方法多时。

更轻量的做法：

• 用匿名结构体快速实现单测所需最小行为：db := &FakeDB{QueryFunc: func(...) {...}}，然后在方法里调用 f.QueryFunc
• 第三方工具如 gomock 或 counterfeiter 自动生成 mock，但注意：生成代码会变多，且接口一改就要重跑
• 优先考虑“真依赖轻量化”：比如用 sqlmock 拦截 *sql.DB 调用，而不是 mock 整个 database/sql 接口

最难的其实是判断什么时候该抽接口：不是所有依赖都需要抽象，比如标准库的 time.Now，用函数变量替代比包级别接口更干净。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！