泛型函数必须显式声明类型参数和约束，否则编译报错；如漏写[T constraints.Ordered]，T被视为未定义标识符；constraints.Ordered要求全序比较，比comparable更严格；调用时仅在类型推导失败（如nil、interface{}、多参数模糊）需手动指定；泛型适用于编译期类型安全与性能场景，非接口替代品。
泛型函数必须显式声明类型参数和约束，否则编译直接报错；不写 [T constraints.Ordered] 就想对 T 做比较或加减，Go 会拒绝编译。
泛型函数声明时漏掉类型参数列表，为什么编译不过
常见错误是写成 func Max(a, b T) T —— 这里 T 是未声明的标识符，Go 编译器根本不知道它是什么。泛型不是“自动识别类型”，而是靠你在方括号里明确定义形参。
正确写法必须带 [T constraints.Ordered] 这类声明：
-
func Max[T constraints.Ordered](a, b T) T：支持int、string、float64等可比较/有序类型 -
func Sum[T constraints.Integer](xs []T) T：只接受整数类型切片，+操作才合法 - 别用
[T any]当万金油——它允许传入任意类型，但函数体内几乎什么都不能做（不能+、不能==、不能调方法）
constraints.Ordered 和 comparable 的区别在哪
Go 1.21+ 推荐用 constraints.Ordered，它比 comparable 更严格也更安全。
立即学习“go语言免费学习笔记（深入）”；
-
comparable只保证能用==和!=，但不支持<、>；所以Max[int]能过，Max[[]int]却会失败（因为切片不可比较） -
constraints.Ordered显式要求类型支持全序比较（<=、>=等），天然排除了[]int、map[string]int这类不可排序类型 - 自定义结构体若想用于
Ordered，得自己实现Less()方法并满足约束接口签名（注意方法名小写）
调用泛型函数时什么时候必须手动指定类型
绝大多数情况不用写 Max[int](1, 2)，Go 能从实参推导出 T = int。但以下场景会推导失败：
- 实参是
nil或未类型化的常量（如Max(nil, nil)或Max(1, 2.5)） - 参数来自
interface{}变量（如var a, b interface{} = 1, 2，此时Max(a, b)报错，因interface{}不满足Ordered） - 多个类型参数且部分模糊（如
func Pair[T, K any](t T, k K)，传入两个nil值时必须写全Pair[string, int](nil, nil)）
泛型 vs interface{}，到底该选哪个
泛型不是接口的升级版，它是另一条技术路径：泛型在编译期生成具体版本，接口在运行时动态绑定。
- 要保持原始类型信息、避免反射开销、防止逃逸（比如操作
[]T时不转成[]interface{}），选泛型 - 只是统一输入出口、行为差异大、或需要跨包/跨服务传递（比如 HTTP handler 参数），用
io.Reader这类接口更轻量 - 强行把
func Process[T io.Reader](r T)改成泛型毫无意义——它没带来类型安全增益，反而增加编译膨胀和理解成本
最容易被忽略的一点：泛型约束一旦写错，错误提示往往不指向约束本身，而是函数体内某行操作（比如 cannot use a + b）。遇到这类报错，第一反应不该是改那行代码，而是回头检查 [T ...] 里填的约束是否真支持这个操作。
