go泛型的类型推断在接口上下文中不生效，仅适用于函数调用和泛型类型字面量；泛型接口如container[t]必须显式指定类型参数，不能通过变量、方法调用或返回值反向推导。
Go 泛型的类型推断在接口（interface）上下文中不生效——它只作用于函数调用和泛型类型字面量，不作用于接口类型本身。接口定义中声明的类型参数不会被“自动猜出”，也不能靠实现方传入的值反向推导。
泛型接口不能被类型推断实例化
泛型接口如 Container[T any] 本身不是可实例化的类型，它只是约束契约。你不能写 var c Container = new(Container[string])，更不能指望编译器从 c.Add("hello") 这样的调用里推出 T = string。
- 接口类型参数必须显式指定，例如
Container[string]、Stack[int] -
interface{ Add(T) }这类带类型参数的嵌入式接口，仍需外部明确绑定T，无法靠方法调用触发推断 - 即使接口只有一个方法且参数是
T，比如func (r Reader[T]) Read() T，r.Read()返回值类型也取决于r的实际类型（如Reader[string]），而非运行时返回值反推
函数参数是泛型接口时，T 必须显式传入或由实参表达式推出
当你写一个接受泛型接口的函数，比如 func Process[C Container[T], T any](c C)，这其实不合法——Go 不允许在函数签名中对泛型接口做双重参数解耦（C 和 T 无法独立约束）。正确写法是把类型参数收束到接口定义侧：
- 定义
type Container[T any] interface { Add(T) }，再写func Process[T any](c Container[T]) - 此时
T能否被推断，**只看传入的c是不是字面量或函数调用表达式**，而不是看c是什么接口 - 如果
c := &MyContainer[string]{}，然后调用Process(c)，T无法推断：因为c是变量，其类型*MyContainer[string]已固定，编译器不从中提取string - 但若直接写
Process(&MyContainer[string]{})，就能推出T = string——因为复合字面量&MyContainer[string]{}显式携带了类型信息
嵌套泛型类型参数推断失败的典型场景
当泛型类型嵌套（如 Map[K, V any] 实现了 Container[Pair[K, V]]），推断链会断裂。编译器不会跨层级“穿透”解析。
-
func UseContainer[C Container[T], T any](c C)→ ❌ 编译错误：Go 不支持这种双层类型参数绑定 - 正确方式是扁平化：把
K和V提到函数顶层，如func UseMap[K, V any](m Map[K, V]) - 即使
Map实现了某个泛型接口，你也**不能靠接口方法签名反推K或V**。例如m.Get("key")返回V，但这个返回值类型对函数调用时的V推断毫无帮助 - 最易踩的坑：以为
func F(c Container[T])+F(myStruct{})能推出T，结果发现myStruct{}没实现Container的完整方法集，或者根本没显式指定T，报错信息往往指向约束不满足，而非推断失败
真正容易被忽略的一点：泛型接口的类型参数不是“虚设”，它参与实例化校验，但完全不参与推断。你必须在每个使用点显式写出类型实参，或确保传入的是能触发推断的表达式（字面量/复合字面量/函数调用），而不是中间变量。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
