泛型函数需显式声明类型约束，如用comparable或Ordered，避免cannot use T as type int错误；类型推导失败常见于nil值、多参数不全传等场景；泛型非interface{}替代品，适用于类型安全、编译期优化场景。
泛型函数怎么写，才不会编译报错
Go 泛型最常卡在 cannot use T as type int 这类错误上——根本原因不是语法写错，而是类型约束没对齐。泛型函数必须显式声明参数能接受哪些类型，不能靠推导“猜”。比如想写一个通用的 Max 函数，直接写 func Max(a, b T) T 会失败，因为 Go 不知道 T 支持 > 操作。
实操建议：
- 用内置约束
comparable或ordered（Go 1.21+）快速起步，比如func Equal[T comparable](a, b T) bool - 需要运算符时，优先查
golang.org/x/exp/constraints（旧版）或直接用constraints.Ordered（1.21+），别自己定义带>的接口 - 自定义约束接口时，方法名必须小写（如
Less()），且不能包含未导出方法，否则实例化失败 - 避免过度抽象：一个只处理
int和float64的函数，硬套泛型反而增加调用开销和可读性负担
interface{} 和泛型到底该选哪个
泛型不是 interface{} 的替代品，而是补位者。当你要做类型安全的转换、保持原始类型信息、或者需要编译期优化（比如切片操作不逃逸），泛型才值得上。
常见误用场景：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只是想传任意值进日志函数？用
interface{}更轻量，泛型在这里纯属杀鸡用牛刀 - 要返回具体类型（比如从 map 取值后直接参与计算），用泛型能省掉
.(*MyType)断言，避免 panic - 泛型函数被高频调用（如每毫秒一次的数值聚合），
interface{}会触发堆分配和反射，而泛型实例化后是静态代码，性能更稳 - 注意：泛型不能用于方法集扩展（比如给
[]T加方法），interface{} 也没法，这得靠包装类型
为什么泛型函数有时无法推导类型参数
Go 的类型推导能力有限，尤其在参数类型不唯一、或存在 nil / 零值时，编译器会放弃猜测，直接报 cannot infer T。
典型触发点：
- 函数有多个泛型参数，但只传了部分实参（比如
func Map[T, U any](s []T, f func(T) U) []U，调用时只传切片不传函数类型，T 和 U 都推不出） - 传入
nil值，比如DoSomething[MyStruct](nil)，Go 无法从nil推出MyStruct，必须显式写成DoSomething[MyStruct]((*MyStruct)(nil)) - 使用内建函数如
len、cap时，如果参数是泛型切片但未标注约束，推导也会失败（需加~[]T或用constraints.Slice） - 嵌套调用时，外层泛型未显式指定，内层就收不到上下文类型信息，比如
Wrap(Foo[T](x))中T可能推导失败
泛型和反射混用时最容易翻车的地方
泛型本身是编译期机制，和运行时反射（reflect 包）天然不搭。强行混合，往往是为了绕过约束限制，结果换来的是不可读、不可调试、且易崩的代码。
真实踩坑点：
- 在泛型函数里对
T做reflect.TypeOf，看似能拿到类型名，但丢失了所有泛型约束语义，后续操作仍需手动判断 - 用
reflect.Value.Convert强转泛型变量，可能触发 panic：类型不兼容，而泛型本意就是杜绝这种运行时错误 - 想通过反射修改结构体字段并保持泛型安全？做不到。泛型不提供字段级约束，
struct{X T}中的X仍是黑盒，反射访问后类型信息已丢失 - 真正需要动态类型的场景（如配置解析、ORM 映射），老实用
interface{}+ 反射，别硬塞泛型——Go 的泛型设计初衷就不是干这个的
泛型的边界很清晰：它解决的是“同一段逻辑，在多种明确类型上复用”的问题。一旦你开始怀疑“这个类型到底是什么”，说明已经滑出泛型的舒适区了。
