go接口实现隐式但方法签名必须完全匹配，包括函数名、参数类型、返回类型及顺序；空接口需类型断言才能调用原方法；嵌入接口须满足所有方法集；mock测试需确保签名一致，集成测试不可少。
接口方法签名不匹配导致编译失败
Go 的接口实现是隐式的，但编译器会严格比对方法签名：函数名、参数类型、返回类型、顺序，哪怕只是 error 和 *errors.Error 这种细微差异，也会被判定为未实现接口。
常见错误现象：cannot use xxx (type *MyStruct) as type MyInterface in assignment: *MyStruct does not implement MyInterface (MissingMethod method has wrong signature)
- 检查是否漏写了指针接收者 —— 如果接口方法定义在
*T上，而你只给T实现了该方法，那T不能赋值给接口，*T才可以 - 注意参数是否用了别名类型：比如
type UserID int和int在方法签名里不兼容，即使底层相同 - 返回值顺序很重要：Go 不允许靠名字匹配，
func() (err error)和func() error是两种不同签名
空接口 interface{} 被误当作“任意类型容器”使用
它确实是任何类型的载体，但一旦存进去，取出来时若没做类型断言或类型转换，就只能当 interface{} 用 —— 无法直接调用原类型方法，也不会触发编译期检查。
使用场景：泛型还没普及前做通用缓存、日志字段、反射入参等；但现在更推荐用泛型替代。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
fmt.Printf("%v", x)来“验证”接口实现 —— 它能输出不代表你能安全调用方法 - 如果本意是约束行为，就定义明确接口，而不是退化到
interface{}+ 运行时 panic - 类型断言失败会 panic，建议用双值形式：
v, ok := x.(MyInterface)，避免静默失败
嵌入接口时漏掉底层依赖方法
接口可以嵌入其他接口，看起来像继承，但 Go 不会帮你自动补全方法。嵌入后，实现该接口的类型必须同时满足所有嵌入接口的方法集。
例如：type ReadWriter interface { Reader; Writer }，那么实现 ReadWriter 的结构体必须同时有 Read() 和 Write() 方法，缺一不可。
- 嵌入多个接口时，注意方法名冲突：两个嵌入接口都有
Close()，但签名不同 → 编译失败 - IDE（如 Goland）可能只提示“missing method”，不会明确指出是哪个嵌入接口缺的，得手动展开查
- 用
go vet或staticcheck可以发现部分遗漏，但不能替代人工核对签名
测试时用 mock 类型绕过接口检查却掩盖真实问题
写单元测试时，常定义一个临时 struct 实现接口来模拟依赖。但如果 mock 实现本身方法签名写错，测试能过，但真实运行时仍 panic —— 因为编译器只校验你传进去的那个 mock 类型，不校验它和真实依赖是否一致。
性能影响不大，但会严重干扰问题定位：错误出现在运行时，而非编译期。
- mock 类型应尽量复用真实接口定义文件，避免手写重复签名
- 考虑用工具如
moq自动生成 mock，它基于源码解析，签名一致性有保障 - 最关键的：集成测试阶段一定要用真实实现跑一遍，否则静态检查的红利就白费了
接口实现的“隐式性”是 Go 的设计选择，不是 bug。但正因如此，方法签名这种细节一旦出错，就不是警告，而是硬性编译失败 —— 没有妥协余地，也藏不住问题。
