泛型编译失败主因是约束缺失、类型未推导或结构体初始化漏类型参数；函数需显式声明类型参数和约束，如func Max[T constraints.Ordered](a,b T)T，结构体必须指定具体类型如Stack[int]{}，且仅在需类型运算或一致性时才适用泛型。
泛型代码写完却编译不过？不是语法错了，大概率是约束没写对、类型没推导出来，或者结构体初始化漏了类型参数。
泛型函数声明必须带类型参数和约束
Go 不会自动识别 T 是什么——它根本不是预定义标识符。写成 func Max(a, b T) T 会直接报 undefined: T。
- 正确写法必须显式声明：
func Max[T constraints.Ordered](a, b T) T -
constraints.Ordered（Go 1.21+ 推荐）比comparable更严格，支持、<code>>、==，天然排除[]int、map[string]int等不可排序类型 - 别用
[T any]当兜底：它允许编译通过，但函数体内连==都不能用，+更是直接报错 - 自定义约束如
type Number interface{ ~int | ~float64 }中的~表示底层类型匹配，int32和int64都能过
泛型结构体初始化必须指定具体类型
Stack[T] 不是“模板类”，而是编译期生成的具体类型。你不能把它当普通结构体用。
- ✅ 正确：
s := Stack[int]{}、var s Stack[string]、new(Stack[float64]) - ❌ 错误：
Stack{}报cannot use untyped composite literal；new(Stack)报undefined: Stack - 字段和方法签名也必须带
[T]：data []T，不是[]interface{}；接收器写成func (s *Stack[T]) Push(v T)，漏掉[T]就会报undefined: T
类型推断失效时必须手动指定类型
大多数时候 Max(1, 2) 能自动推导出 T = int，但以下情况推导失败，不写全就编译不过。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 实参是
nil：Max(nil, nil)→ 必须写Max[*int](nil, nil) - 参数来自
interface{}变量：var a, b interface{} = 1, 2→Max(a, b)报错，因interface{}不满足Ordered - 多个类型参数且模糊：
Pair[string, int](nil, nil)必须写全，否则无法确定每个参数类型 - 错误信息常指向泛型实例化位置而非调用行，先检查实参是否明确、是否满足约束
泛型不是 interface{} 的替代品
如果函数只是透传、打印或序列化（比如 Log(v interface{})），加泛型纯属冗余。
- ❌ 多余：
func Log[T any](v T)没带来任何收益，还增加编译负担 - ✅ 该用泛型的场景很明确：要对元素做运算（
+、>）、深比较、或保证类型一致性（如Map[K comparable, V any]） - 泛型在编译期完成类型检查和代码生成，性能优于
interface{}+ 类型断言，但前提是真有类型操作需求
最容易被忽略的是约束和实参类型的隐式耦合：一个 constraints.Ordered 函数，传进去 []string 没问题，但传 [][]string 就会失败——因为切片本身不支持 ，约束检查在编译期就卡住了，不会等到运行时。
