Go 泛型中的类型推导：编译器什么时候能推断，什么时候必须显式指定

先从几个例子说起

运行下面的代码，看看哪些能编译，哪些会报错：

func First[T any](s []T) T {
    return s[0]
}

func Zero[T any]() T {
    var t T
    return t
}

_ = First([]int{1, 2, 3}) // 正常编译
_ = Zero[int]()           // 正常编译
_ = Zero()                // cannot infer T

这种差异在刚接触泛型时很迷惑。Zero 的 T 只出现在返回值里，调用的时候没有任何一个普通入参能告诉编译器“T 是什么”。而 First 的 T 出现在 []T 里，传入 []int 后编译器能顺理成章地把 T 绑定到 int。

所以第一个判断标准很朴素：一个类型参数要想被推导，至少要和某个函数实参的类型产生联系。这个联系可以由参数类型本身构建，也可以由参数类型与约束之间的嵌套关系构建。

类型参数在参数中的位置决定能否推导

常见的可推导形式有这几种：

func Identity[T any](v T) T                       // T = v 的类型
func Pick[T any](arr []T, i int) T                // T = arr 的元素类型
func Merge[T any](a, b []T) []T                   // 两个参数互相校验，T 取同类型
func Transform[T, R any](s []T, f func(T) R) []R  // T 从第一个参数来，R 从 f 返回类型来

Merge 比较有意思：传入 a 是 []int，b 是 []string，编译器会尝试统一两个实参类型，发现一个要求 T = int，一个要求 T = string，冲突，于是报错。这就是“统一”的含义——不是选一个，而是寻找同时满足所有约束的单一映射。

还有一种情况经常被忽略：参数中的类型参数被“包”在另一个类型参数后面，例如 func FirstElem[T any, S ~[]T](s S) T。这里 S 是一个切片类型，但切片元素类型被单独建模成 T。调用 FirstElem([]int{1}) 时，编译器先匹配 S = []int，发现约束是 ~[]T，于是进一步得到 T = int。这种“约束推导”在泛型版本 1.18 之后逐渐完善，也是很多第三方库实现类型安全集合的基础。

有清晰的推导路径，意味着编译器不需要猜测。但很多开发者会误以为“Go 的推导能力比 Java 弱”，其实不是能力弱，而是设计边界不同：Go 明确定义了推导只能依赖函数调用时的实参类型和已有约束，不会因为返回值类型而被“推着走”。

必须显式指定的几种典型情况

对照“必须和实参类型产生联系”这句话，我们可以列出几个必然需要显式指定的情况：

类型参数只出现在返回值中，如 func Nil[T any]() *T。
类型参数只出现在函数体内的局部变量类型中，外部看不见。
类型参数在多个返回值中出现，但没有任何一个普通参数指向它。
泛型类型作为类型字面量构造时，例如 type List[T any] struct{} 的 List[int]{}。

其中第一类与第四类在现实代码中最常见。尤其是构造泛型容器时，很多初学者会写：

type Cache[T any] struct {
    data map[string]T
}

func NewCache[T any]() *Cache[T] {
    return &Cache[T]{data: make(map[string]T)}
}

然后调用 NewCache[string]()。为什么不能写 NewCache()？因为 T 同样没有出现在普通函数参数中，编译器得不到任何提示。解决方式之一是让构造函数至少接收一个与 T 有关的值：

func NewCache[T any](items ...T) *Cache[T] {
    cache := &Cache[T]{data: make(map[string]T)}
    // 用 items 初始化，或只是让 T 可被推导
    return cache
}

_ = NewCache("a", "b") // 编译器可以推导 T = string

这是我建议泛型 API 设计者努力的方向：尽量让每个公开构造函数都能通过一个可变参数来表达“核心元素类型”。如果实在做不到，那就在文档里明确写出显式调用方式，要求用户习惯 NewCache[string]() 这样的写法。

还有一种必须显式的情况是“只给一部分类型参数”的写法。Go 不允许 Pair[int] 这种部分指定，因为类型实参列表要么整体省略，要么整体给出。下面的代码会报错：

func Pair[T, U any](a T, b U) (T, U) { return a, b }

pair := Pair[int]("x") // 编译错误：类型参数个数不匹配
pair := Pair[int, string]("x", 1) // 必须写全

这其实是一个很典型的“想把推导和显式混合”的愿望，但 Go 并没有这种便捷模式。如果你真的需要部分可推导、部分显式，可以拆成两个函数，或者给返回值增加一个对应的参数。

常见误区：看到 cannot infer T 就以为是编译器坏了

下面这些场景我见过不止一次，在 Go 社区提问里也非常高频。

误区一：把类型参数写在返回值的泛型类型里，然后期望根据等号左边的变量类型推导。

var result int = someGeneric[int]() // 显式写了，没问题
var result2 int = someGeneric()      // 编译器不会通过 target 类型推导

Go 的赋值依赖方向是从右边的表达式产生类型，再检查能否赋值给左边。它不会反过来根据左边“补全”表达式缺失的类型参数。这是语言设计上的克制：保持类型推导局部性和可读性。

误区二：认为约束也能“反向指导”调用方。例如：

func Parse[T any](s string) T { ... }

你可能会想：约束是 any，那 T 应该可以根据调用处想要 int 来推导。但编译器不会看调用点期望的类型，它只看函数定义和调用参数。这里 s 的类型是 string，它和 T 没有任何结构上的联系，所以推导必败。

误区三：把“推导失败”和“泛型类型不支持”混为一谈。例如在使用第三方泛型库时，库函数定义为 func Of[T any](value T) T，你传了一个 interface{} 变量进去，编译器确实可以把 T 推导为 interface{}，这时结果类型也是 interface{}，不是具体类型。如果库作者希望用户传入具体类型，他应该在约束里排除 interface{}，或者通过其他方式约定，但这属于 API 设计问题，不是推导失效。

显式指定并不是坏事，但要分清场景

使用显式类型参数会让代码更啰嗦，但换来的确定性和可读性是值得的。我在下面这几个场景中更倾向显式：

返回值是接口类型。如果不显式指定，编译器会将类型参数绑定为实参的具体类型，而不是返回你期望的抽象类型。
团队里新人多，显式写出类型参数能显著降低读代码的理解成本。
项目的 Go 版本比较旧，或者团队刚从 Go 1.17 迁移过来，对推导边界不熟，显式写法可以少踩坑。

下面这张表可以帮助你快速决策什么情况下切换写法：

调用形态	推荐策略	原因
类型参数全部能从普通参数推导	隐含	代码简洁，IDE 一般也能给出正确提示
仅一个类型参数无法推导	显式全部	Go 不支持部分显式，写全最直接
函数是公开库 API，调用方不确定	提供可推导的构造器 + 显式兜底	让调用方自己选择风格
泛型类型字面量初始化	必须显式	类型字面量没有推导机制

这张表没有对错，更多是优先级。比如你的项目里所有泛型函数都只有一个类型参数，且只出现在参数里，那隐式写法几乎不出问题。可一旦进入多个类型参数相互依赖的领域，显式写出来反而让人安心。

如何设计一个“推导友好”的泛型 API

如果你正在写泛型库，下面这些经验值得收藏。

第一，让类型参数出现在普通参数里，并且最好出现在可变参数里。这样调用方用最少的参数就能触发推导。比如标准库的 slices 包几乎都是 func Xxx[S ~[]E, E any](s S) ... 的结构，天然可推导。

第二，避免让类型参数只出现在返回值中。如果返回值确实需要类型参数，可以考虑在函数参数里加一个“样例”参数。例如你要设计一个泛型序列化函数，可以写成 func Unmarshal[T any](data []byte, dst *T) error，这样 T 可以通过 dst 推导出来：

var v MyStruct
err := Unmarshal(data, &v)
// T 推导为 MyStruct，调用方不用写 Unmarshal[MyStruct](data, &v)

第三，少用“约束推导”作为主要机制。虽然它很有用，但链条太长时，编译器的推导失败信息会很令人困惑。比如 func F[K constraints.Ordered, V any, M ~map[K]V](m M) 调用 F(map[string]int{}) 时，要从 M 推导 K 和 V 很容易，但如果调用方传错了 map 类型，报错信息会指向 M 不匹配，而不是 K 或 V，调试成本反而上升。

第四，善用类型别名。在某些场景下，显式写一个类型参数反而是 API 的明确意图，不需要强行隐藏。

一个更完整的例子：可推导的容器构造函数

我把前面提到的 Cache 扩展一下，给出一个完整可运行的思路：

func NewCache[T any](items ...T) *Cache[T] {
    cache := &Cache[T]{data: map[string]T{}}
    for i, v := range items {
        cache.data[fmt.Sprintf("key%d", i)] = v
    }
    return cache
}

c1 := NewCache[int]()          // 显式，没问题
c2 := NewCache(1, 2, 3)        // 推导为 int
c3 := NewCache[string]()       // 显式空 cache

这里 NewCache() 没有参数就无法推导，但通过可变参数 ...T 让 T 获得了从参数列表推断的可能。注意 ...T 和 []T 在推导上是不同的：...T 在函数调用时是“逐元素”展开，编译器把每个实参都作为 T 的来源，所以 NewCache(1,2,3) 可以直接得到 T = int，而不会错误地推导为 T = []int。这也是很多泛型构造器惯用的手法。