Go语言函数签名匹配的严格性
在go语言中，当尝试将一个函数赋值给一个函数类型的变量时，编译器会要求函数签名（包括参数类型和返回值类型）必须精确匹配。这种严格性在处理接口类型时尤为突出，即使一个接口类型fooerbarer嵌入了另一个接口类型fooer，并且从语义上讲fooerbarer“是一个”fooer，但返回fooerbarer的函数仍然不能直接赋值给期望返回fooer的函数变量。
考虑以下示例，它清晰地展示了这种行为：
// 定义一个Fooer接口
type Fooer interface {
Foo()
}
// 定义一个FooerBarer接口，它嵌入了Fooer接口
type FooerBarer interface {
Fooer // 嵌入Fooer
Bar()
}
// 定义一个结构体，实现FooerBarer接口
type bar struct{}
func (b *bar) Foo() {}
func (b *bar) Bar() {}
// 定义一个函数类型FMaker，它期望返回Fooer接口
type FMaker func() Fooer
/* 定义FMaker类型的变量 */
// 1. 这种赋值方式是允许的，因为函数签名精确匹配FMaker类型
var fmake FMaker = func() Fooer {
return &bar{} // &bar{}实现了FooerBarer，因此也实现了Fooer，这里返回Fooer是合法的
}
// 2. 这种赋值方式会导致编译错误，即使FooerBarer“是”一个Fooer
// 错误信息类似："cannot use func() FooerBarer literal (type func() FooerBarer) as type FMaker in assignment"
var fmake2 FMaker = func() FooerBarer {
return &bar{}
}上述代码中的第二个赋值操作会引发编译错误。尽管FooerBarer包含了Fooer的所有方法，并且&bar{}类型实现了FooerBarer，因此也实现了Fooer，但编译器仍然拒绝了func() FooerBarer到FMaker（即func() Fooer）的直接赋值。
为什么编译器如此严格？
这种严格行为的根本原因在于Go语言接口的内部实现和类型系统的设计哲学。
-
接口的运行时表示与itable： 在Go语言内部，一个接口值由两部分组成：一个指向其具体类型数据的指针和一个指向该具体类型实现该接口的方法表（itable）的指针。itable存储了接口方法的实际函数地址。
- Fooer接口和FooerBarer接口，尽管FooerBarer嵌入了Fooer，但它们是两个不同的接口类型。它们在运行时对应着不同的itable结构。
- 当一个函数被声明为返回Fooer时，它承诺返回一个其itable布局与Fooer类型定义相匹配的接口值。如果允许它返回FooerBarer，那么返回的接口值在调用方看来，其itable结构可能与Fooer预期的不同（例如，方法的顺序或数量可能不完全一致，即使FooerBarer的方法集是Fooer的超集）。如果在运行时进行方法查找，可能会导致查找错误的地址，从而引发程序崩溃或不可预测的行为。
-
Go语言的类型系统不进行自动转换： Go语言的类型系统设计理念是明确且严格的，它在类型转换方面非常保守。
- 非接口类型的自动转换： Go不会在不同类型之间自动进行转换，即使它们的底层类型相同或兼容。例如，你不能将float64自动赋值给int，也不能将time.Duration（底层是int64）自动赋值给int64变量。你必须进行显式类型转换。
-
函数类型的自动转换： 这种严格性也延伸到了函数类型。func() FooerBarer和func() Fooer被视为完全不同的类型。Go编译器不会自动“包装”一个函数，使其返回值进行隐式转换。如果允许这样做，将会引入：
- 运行时开销： 每次调用函数时都需要进行一次隐式类型转换，增加了不必要的开销。
- 不一致性： 与Go在其他类型转换上的严格性原则相矛盾。
- 复杂性： 自动包装函数的行为会使类型系统的行为变得更加复杂和难以预测。
接口值赋值与函数签名赋值的区别
理解这一点，关键在于区分“接口值的赋值”和“函数签名的赋值”。
立即学习“go语言免费学习笔记（深入）”；
-
接口值的赋值（隐式/显式转换）： 当一个FooerBarer类型的值被赋值给一个Fooer类型的变量时，Go语言是允许的，并且会进行隐式或显式转换。
-
显式转换示例：
var myFooerBarer FooerBarer = &bar{} var f Fooer = myFooerBarer // 隐式转换 // 或者显式转换：var f Fooer = Fooer(myFooerBarer) f.Foo() // 这是合法的在这种情况下，运行时会检查myFooerBarer的具体类型（*bar），然后查找*bar类型实现Fooer接口的itable，并创建一个新的Fooer接口值。这个过程是安全的，因为FooerBarer保证拥有Fooer的所有方法。
- 函数参数的隐式转换： 如果有一个函数 func(f Fooer)，你可以直接传入一个FooerBarer类型的值。编译器会为函数参数进行上述的隐式接口值转换。
-
显式转换示例：
函数签名的赋值（无自动转换）： 然而，在函数签名赋值的场景中，例如 var fmake2 FMaker = func() FooerBarer { ... }，你尝试赋值的是整个函数类型，而不是其返回值。Go编译器不会自动修改或包装这个函数的定义，使其返回值在每次调用时都进行转换。它要求左右两边的函数类型必须是完全相同的。
解决方案
如果你确实需要将一个返回FooerBarer的函数赋值给一个期望返回Fooer的函数变量，你需要手动“包装”这个函数，显式地在函数内部进行返回值的类型转换。
// 原始的返回FooerBarer的函数
var fbmake = func() FooerBarer {
return &bar{}
}
// 定义一个FMaker类型的变量
var fmake FMaker
// 通过包装函数，显式地将fbmake的返回值转换为Fooer
fmake = func() Fooer {
return fbmake() // 调用fbmake()获取FooerBarer，然后Go运行时会将其隐式转换为Fooer
}
// 现在fmake可以正常使用
fmake().Foo()在这个解决方案中，func() Fooer的函数体内部调用了fbmake()，fbmake()返回一个FooerBarer接口值。当这个FooerBarer值被return语句返回时，它被赋值给func() Fooer的返回值类型Fooer。在这个赋值过程中，Go语言的接口值转换机制会启动，将FooerBarer值转换为Fooer值，从而满足了函数签名的要求。
总结
Go语言编译器对函数签名的严格匹配要求是其类型系统健壮性和可预测性的体现。它避免了运行时潜在的itable不匹配问题，并坚持了不进行自动类型转换的设计哲学。虽然接口值可以在赋值时进行隐式或显式转换，但这种机制不适用于函数类型本身的赋值。理解这一区别，并采用显式包装函数的方法，是处理此类场景的正确途径。
