go 中接口是严格的契约式约定，即使两个接口方法签名相同，只要返回类型不同（如 material1 和 material2），就视为不兼容；必须统一为共同的底层接口（如 material）才能实现跨接口赋值。
go 中接口是严格的契约式约定，即使两个接口方法签名相同，只要返回类型不同（如 material1 和 material2），就视为不兼容；必须统一为共同的底层接口（如 material）才能实现跨接口赋值。
在 Go 语言中，接口的实现关系是显式且精确匹配的——编译器不会基于方法行为或语义进行推断。你遇到的错误：
cannot convert m1 (type Machine1) to type Machine2:
Machine1 does not implement Machine2 (wrong type for Produce method)
have Produce() Material1
want Produce() Material2根本原因在于：Go 不支持接口间的隐式转换，哪怕 Material1 和 Material2 具有完全相同的方法集（Use() error）。这是因为：
- Material1 和 Material2 是两个独立定义的接口类型；
- 即使 *Pencil 同时实现了二者，Machine1.Produce() 的返回类型声明为 Material1，它不等于 Material2；
- 接口赋值要求方法签名完全一致（包括参数类型、返回类型、名称），而 Material1 ≠ Material2，因此 Machine1 无法满足 Machine2 的契约。
✅ 正确做法：提取公共抽象，统一返回类型
将分散的 Material1/Material2 合并为一个共享接口 Material，让所有生产者都返回该类型：
package main
type Material interface {
Use() error
}
type Machine1 interface {
Produce() Material // ← 统一返回 Material
}
type Machine2 interface {
Produce() Material // ← 同样返回 Material
}
type PencilMachine struct{}
func (pm *PencilMachine) Produce() Material {
return &Pencil{} // ✅ 同时满足 Machine1 和 Machine2
}
type Pencil struct{}
func (p *Pencil) Use() error {
return nil
}
func main() {
pm := &PencilMachine{}
var m1 Machine1 = pm // ✅ PencilMachine 实现 Machine1
var m2 Machine2 = m1 // ✅ 因为 Machine1.Produce() 返回 Material，而 Machine2 也期望 Material
_ = m2
}⚠️ 注意事项：
- 不要依赖“看起来一样”的接口：interface{ Use() error } 与 interface{ Use() error } 若为两个独立定义，仍是不同类型；
- 若需临时桥接（如测试中模拟），可通过适配器函数或包装结构体显式转换：
func adaptMachine1ToMachine2(m1 Machine1) Machine2 { return machine2Adapter{m1} } type machine2Adapter struct{ m Machine1 } func (a machine2Adapter) Produce() Material { return a.m.Produce() } // 前提：Material 是共同接口 - 在设计 API 时，优先定义最小、稳定的公共接口（如 Material），避免因接口碎片化导致耦合和转换障碍。
总结：Go 的接口兼容性是结构化且不可推导的。与其尝试绕过类型系统，不如从设计源头统一契约——这既是 Go 的约束，也是其清晰性与可维护性的基石。
