Go泛型类型推断仅基于调用时的实参表达式，不依赖变量声明；需实参为字面量、复合字面量或函数调用表达式才能触发推断，且多类型参数须各自独立无歧义推出，约束仅校验不参与推断。
泛型调用时的类型推断只看实参，不看变量声明
Go 的泛型类型推断发生在函数或类型实例化那一刻，和 := 声明无关。比如 Print([]int{1, 2, 3}) 能推断出 T = int，是因为切片字面量 []int 明确携带了元素类型；但 var s = []int{1, 2, 3}; Print(s) 就无法推断——因为 s 是一个已声明变量，其类型是 []int，而泛型函数只从**调用时传入的实参表达式本身**提取类型信息。
常见错误现象：
-
var data []string = getStrings(); Map(data, f)→ 编译失败：无法推断T -
Map(getStrings(), f)→ ✅ 成功，getStrings()返回值类型直接参与推断
所以别指望“先存变量再传进去”还能触发推断。想让推断生效，就得让实参是字面量、复合字面量、或函数调用表达式本身。
多个类型参数推断失败的典型场景
当泛型有多个类型参数（如 [K, V any]），编译器必须能从实参中**独立、无歧义地推出每个参数**。只要有一个推不出来，就报错，不会只推部分。
立即学习“go语言免费学习笔记（深入）”；
例如：
type Pair[K, V any] struct{ First K; Second V }-
p1 := Pair[string, int]{First: "a", Second: 42}→ ✅ 显式指定，没问题 -
p2 := Pair[string]{First: "a", Second: 42}→ ✅ 第二个参数由Second: 42推出为int -
p3 := Pair{First: "a", Second: 42}→ ❌ 报错：无法推断K和V，因为没提供任何类型锚点
关键点：推断不是“猜”，而是“唯一解”。Pair{...} 这种写法在 Go 中不支持全隐式推断，必须至少显式写出一个类型参数，或让字段初始化值足够明确（如上例中 Pair[string] 已锁定 K，Second 的值就能反推 V）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
约束（constraint）不参与推断，只做校验
类型约束（如 constraints.Ordered 或 int | float64）的作用是**过滤掉不合法的实参类型**，而不是帮助编译器“缩小范围”去猜类型。
举例：
func Min[T constraints.Ordered](a, b T) T-
Min(1, 2)→ 推出T = int，然后检查int是否满足constraints.Ordered→ ✅ -
Min(1, 2.0)→ ❌ 直接报错：两个实参类型不同（intvsfloat64），根本走不到约束检查那步
也就是说，推断阶段只管“这个值是什么类型”，约束阶段才管“这个类型能不能用”。不要误以为加了 int | float64 就能让 Min(1, 2.0) 自动选一个——它连推断都过不去。
泛型推断和变量声明推断完全隔离
很多人混淆 a := SomeGenericFunc(...) 中的两层推断：左边 a 的类型由函数返回值决定（这是变量声明推断），右边 SomeGenericFunc(...) 的类型参数由实参决定（这是泛型推断）。这两件事互不影响，也不共享逻辑。
比如：
-
result := Map([]string{"a", "b"}, strings.ToUpper)→result类型被推为[]string（因为Map返回[]U，而strings.ToUpper返回string，所以U = string） - 但这个过程里，
Map的T是从[]string推出的，U是从strings.ToUpper的函数签名推出的 —— 它们各自独立完成
最容易被忽略的一点：如果你写 var result = Map(...)，那么变量声明这层就**不触发类型推断**（var = 在 Go 中非法），必须写成 var result []string = Map(...) 或直接用 :=。泛型推断本身倒不受影响，但整个语句得先语法正确才行。
