Go 泛型函数只从返回值使用类型时为什么推导失败

遇到 func MakeZero[T any]() T 时，很多人会自然地认为 var n int = MakeZero() 应该让编译器知道 T 是 int。但 Go 不会从接收返回值的变量反向推导这个类型参数。这个调用没有携带可用于建立类型关系的函数实参，因此通常会得到 cannot infer T。直接写成 MakeZero[int]()，或重新设计一个带 typed 参数的 API，才是稳定的解决方式。

为什么返回值不能替代函数实参

先看一个最小例子：

package main

// MakeZero 只把 T 放在返回值中，没有输入参数。
func MakeZero[T any]() T {
	var zero T
	return zero
}

func main() {
	// 编译器不能从 n 的 int 类型反推出 T。
	var n int = MakeZero()
	_ = n
}

这里有两个不同阶段：先要实例化泛型函数，得到一个具体的 MakeZero[T]；实例化完成后，返回值才有具体类型。赋值目标只是在结果已经确定后检查能否赋值，并不是函数调用的类型实参来源。

Go 规范把函数调用中的对应实参与形参写成类型方程。若调用没有实参，就没有 实参 ≡ 形参 这条方程可用于求解 T。官方泛型介绍也明确区分了这种函数实参推导：只用于出现在函数参数中的类型参数，不覆盖只出现在结果或函数体里的参数。

把类型参数放到可观察的参数位置

如果 API 确实希望省略方括号，就必须让调用现场出现带类型的输入。例如把零值作为 typed 参数传入：

package main

// MakeFrom 返回与模板值相同类型的零值。
func MakeFrom[T any](template T) T {
	var zero T
	return zero
}

func main() {
	// 显式转换让模板值稳定地表达 int。
	n := MakeFrom(int(0))
	_ = n
}

此时编译器可以把实参 int 与形参 T 对齐，推出 T=int。不过这个参数不是免费的：它可能只是为了帮助推导而存在，调用方还要构造一个模板值。若函数本来就有业务输入，通常应该让已有输入承担这个角色，而不是添加一个没有业务意义的参数。

无参数泛型工厂该怎么设计

对真正没有输入的工厂，显式类型实参往往是最清楚的 API：

package main

// NewBuffer 创建指定元素类型的空缓冲区。
func NewBuffer[T any]() []T {
	return make([]T, 0)
}

func main() {
	// 类型信息直接写在调用处，读者无需猜测推导来源。
	buf := NewBuffer[byte]()
	_ = buf
}

另一种方案是把类型绑定到已有的函数值或配置对象上，但本质仍然是让 T 出现在调用参数的类型里。选择时可以看三点：调用是否高频、模板参数是否有真实语义、显式类型实参是否更容易阅读。不要为了追求少写一对方括号而制造“伪参数”。

编译器推导失败时的排查顺序

最后记住：推导失败并不代表泛型函数本身错误，而是当前调用现场没有足够、且不含歧义的类型信息。先找实参与形参的关系，再看约束能否继续收敛；如果没有输入，显式类型实参就是预期用法。

相关问题

赋值左侧写了具体类型，为什么还不能推导？

左侧类型用于检查返回结果，不会作为这次泛型函数调用的推导方程。只要函数参数里没有可绑定 T 的输入，就应显式写类型实参。

增加一个参数后是不是总能推导成功？

不一定。参数必须真正携带类型信息，且多个实参之间不能推出冲突的类型；无类型常量还可能先按默认类型参与后续判断。

参考：Go 语言规范：Type inference；Go 官方博客：An Introduction To Generics。