Go语言在1.18前无泛型，反射可模拟泛型行为但性能差、无类型安全；自1.18起应优先使用泛型实现类型安全的通用逻辑，反射仅用于需动态处理未知结构的场景。
Go 语言在 1.18 版本之前没有原生泛型支持，开发者常借助反射（reflect）来模拟泛型行为。虽然反射能实现一定程度的类型通用性，但它并不能真正替代泛型，尤其在性能和类型安全方面存在局限。
反射模拟泛型的基本原理
通过 reflect.Value 和 reflect.Type，可以在运行时获取变量的值和类型信息，进而对不同类型的数据执行相似的操作。这种机制让函数可以“接收任意类型”，从而模拟泛型函数的行为。
例如，实现一个通用的打印或比较函数：
- 使用 reflect.ValueOf() 获取值的反射对象
- 调用 .Kind() 判断基础类型（如 slice、struct、int 等）
- 通过 .Elem() 访问指针或切片元素
- 利用 .Call() 动态调用方法（如果存在）
这种方式可以让一个函数处理 int、string、自定义结构体等不同类型的输入，看似实现了“泛型”功能。
立即学习“go语言免费学习笔记（深入）”；
动态调用方法与类型推断限制
反射支持通过方法名字符串查找并调用方法（MethodByName），这可用于模拟动态多态。但 Go 编译器无法在编译期验证这些调用是否合法，导致错误只能在运行时暴露。
类型推断方面，反射不具备编译期类型推导能力。比如你传入一个 []int，反射知道它是切片，也知道元素是 int，但无法像泛型那样将元素类型作为模板参数传递给另一个操作。
常见问题包括：
- 性能开销大：反射涉及大量运行时检查
- 无编译时类型检查：类型错误在运行时才被发现
- 代码复杂难维护：需要写很多样板代码判断类型分支
- 无法返回具体类型：通常只能返回 interface{} 或 reflect.Value
Go 泛型（Type Parameters）才是正解
从 Go 1.18 起，语言原生支持泛型。你可以这样写：
func Map[T any, R any](slice []T, f func(T) R) []R {
result := make([]R, len(slice))
for i, v := range slice {
result[i] = f(v)
}
return result
}
这个函数在编译期为每种实际类型生成对应代码，兼具类型安全和高性能。相比反射，它：
- 编译期类型检查：传参错误立刻报错
- 零运行时开销：没有反射调用的额外成本
- 更清晰的语义：类型参数明确表达意图
何时使用反射？何时用泛型？
如果你的目标是实现类型通用逻辑（如序列化、ORM 映射、配置解析），且涉及未知结构，反射仍是必要工具。但如果是算法复用（如容器操作、转换、校验），应优先选择泛型。
总结来说，反射可以“模拟”泛型的部分行为，但不能真正实现类型参数化编程。它更适合元编程场景，而非日常的通用逻辑抽象。
基本上就这些，别再用反射硬搞泛型了，有泛型不用才是真折腾。
