go 接口是严格的契约式类型，即使两个接口方法签名相同、底层实现类型能同时满足两者，只要方法返回类型不同（如 produce() material1 与 produce() material2），就无法隐式转换——必须统一为同一接口类型才能复用。
go 接口是严格的契约式类型，即使两个接口方法签名相同、底层实现类型能同时满足两者，只要方法返回类型不同（如 produce() material1 与 produce() material2），就无法隐式转换——必须统一为同一接口类型才能复用。
在 Go 中，接口的实现关系是静态且显式的：一个类型是否实现某个接口，完全取决于其方法集是否字面量匹配该接口定义的方法签名（包括参数类型、返回类型和数量）。这与“鸭子类型”或运行时动态检查有本质区别。
例如，虽然 Pencil 同时实现了 Material1 和 Material2（二者均只含 Use() error），但 PencilMachine.Produce() 的签名是 func() Material1，它不等于 func() Material2——哪怕 Material1 和 Material2 行为一致、甚至底层结构相同。Go 编译器不会做跨接口的返回类型推导或自动适配。
因此，以下代码会编译失败：
var m1 Machine1 = &PencilMachine{}
var m2 Machine2 = m1 // ❌ 错误：Machine1 不实现 Machine2
因为 Machine1.Produce() 返回 Material1，而 Machine2.Produce() 要求返回 Material2；二者是不同的类型，不可互换。
✅ 正确做法是抽象出公共接口，让多个机器共用同一契约：
package main
type Machine1 interface {
Produce() Material // 统一返回 Material
}
type Machine2 interface {
Produce() Material // 同上
}
type Material interface {
Use() error
}
type PencilMachine struct{}
func (pm *PencilMachine) Produce() Material {
return &Pencil{} // 返回 Material，而非 Material1 或 Material2
}
type Pencil struct{}
func (p *Pencil) Use() error {
return nil
}
func main() {
pm := &PencilMachine{}
var m1 Machine1 = pm
var m2 Machine2 = pm // ✅ 成功：pm 同时满足 Machine1 和 Machine2
_ = m1
_ = m2
}
? 关键提示：
- Go 中不存在“接口继承”或“接口等价推导”，Material1 和 Material2 即使方法完全相同，也是两个独立类型；
- 若需复用行为，应提前设计共享接口（如 Material），而非事后尝试强制转换；
- 测试中做 mock 时，优先让被测对象实现最小、通用、稳定的接口，避免因细粒度接口分裂导致类型不兼容。
这种设计强化了 Go 的显式性与可维护性——所有依赖关系清晰可见，杜绝隐式耦合，也正因此，Go 的接口更易测试、更易演化。
