Go function inference 怎样在让赋值场景推导泛型（输入边界）

Go 1.27 里的 function inference，关键不只是“调用泛型函数时省略类型参数”，还包括把泛型函数当作函数值使用。只要接收位置已经给出一个匹配的非泛型函数类型，编译器就能从这个目标签名反推出类型参数。例如 IntFormatter 明确要求 func(int) string，所以 GenericFormatter 的 T 可以推导为 int。

本文只讨论这种“目标类型提供输入”的边界，示例按 Go 1.27 语言规则说明。官方规范入口：https://go.dev/ref/spec。

目标函数类型决定 T 是什么

package main

import "fmt"

// T 只出现在输入参数中，调用点需要一个外部目标来提供它。
func GenericFormatter[T any](v T) string {
    // 这里把输入值格式化为文本，返回类型固定为 string。
    return fmt.Sprintf("value: %v", v)
}

// 目标类型把 T 限定为 int。
type IntFormatter func(int) string

func main() {
    // Go 1.27：从 IntFormatter 的参数类型推导 T = int。
    var format IntFormatter = GenericFormatter
    fmt.Println(format(42))
}

推导可以拆成三件事：左侧的 IntFormatter 展开为 func(int) string；右侧泛型函数的输入参数是 T；两者需要满足可赋值关系，于是得到 T = int。实例化后，右侧不再是泛型函数，而是一个普通的 func(int) string 函数值。

赋值位置必须真的有目标签名

最稳妥的写法是先声明函数类型，再把泛型函数交给它。也可以把它作为参数传给一个签名明确的函数；本质仍然是接收方先提供了非泛型函数类型。

package main

import "fmt"

func GenericFormatter[T any](v T) string {
    // 保持示例的输入类型由接收方决定。
    return fmt.Sprintf("value: %v", v)
}

type IntFormatter func(int) string

func useFormatter(f IntFormatter) string {
    // 参数类型已经固定，所以调用者可以省略 GenericFormatter 的类型实参。
    return f(7)
}

func main() {
    // 变量类型提供目标签名。
    var f IntFormatter = GenericFormatter
    fmt.Println(f(1))

    // 函数参数类型同样提供目标签名。
    fmt.Println(useFormatter(GenericFormatter))
}

这里不能把“左侧有变量”简单理解成“总能推导”。var f IntFormatter 有明确函数签名；而 f := GenericFormatter 没有目标类型，编译器不知道 T 应该是什么，因此仍需要写成 GenericFormatter[int]，或者先定义一个明确的函数类型。

Go 1.27 还扩展了哪些赋值上下文

Go 1.27 的变化覆盖了更多“泛型函数必须被赋给某个非泛型函数类型”的位置。下面四种写法的共同点不是语法相似，而是每个位置都能提供 func(int) string 这样的目标签名。

package main

import "fmt"

func GenericFormatter[T any](v T) string {
    // 返回值类型固定，T 由目标函数类型提供。
    return fmt.Sprintf("value: %v", v)
}

type IntFormatter func(int) string

func main() {
    // 切片元素类型是目标函数类型。
    formatters := []IntFormatter{GenericFormatter}

    // 转换目标明确要求 func(int) string。
    fn := IntFormatter(GenericFormatter)

    // 通道元素类型提供同一个目标签名。
    ch := make(chan IntFormatter, 1)
    ch 

复合字面量、函数类型转换和通道发送并没有改变泛型函数的定义；它们只是让“目标类型在哪里出现”变得更丰富。维护代码时可以先找接收位置：看它是否明确写出了函数参数和返回值，再判断能否省略类型实参。

四个输入边界要先分清

如果目标是 any 或一个无法确定具体函数签名的接口，它不能告诉编译器 T 是什么；目标签名与泛型函数不匹配时也不会“猜一个最接近的类型”。类型推导成功后仍要经过普通的约束检查和可赋值检查，推导不是对类型错误的放宽。

写泛型函数值时的核对方式

• 先确认接收位置是非泛型函数类型，而不是宽泛的 any。
• 把参数类型和返回类型分别对照，不能只看参数名相同。
• 没有目标签名时，使用 GenericFormatter[int] 明确实例化。
• 跨 Go 版本迁移时，确认模块和构建工具链确实使用 Go 1.27 语义。

为什么 GenericFormatter 不能单独赋给 any？ 因为 any 没有提供具体函数参数类型，编译器无法据此推导 T。

显式写 GenericFormatter[int] 还可以吗？ 可以。上下文推导减少了重复，不会禁止在需要强调意图或消除歧义时显式提供类型参数。