泛型解决编译期类型复用，反射解决运行时类型未知；泛型零开销但无法处理字段级动态操作，反射灵活却有性能损耗和panic风险，二者分层协作而非替代。
泛型解决编译期类型复用，反射解决运行时类型未知——两者定位不同，不是替代关系，而是分层协作。
泛型：编译期特化，零运行时开销
泛型在 Go 1.18+ 中通过类型参数 T 实现，编译器会为每个实际类型（如 int、string）生成专用函数版本，不依赖 interface{} 或运行时类型检查。
- 类型安全由编译器保障：
func Print[T any](v T)传入int就只能传int，错类型直接报错 - 无反射调用开销：不涉及
reflect.ValueOf、reflect.Type等，性能接近手写单类型函数 - 不能处理“编译期完全未知”的场景：比如从 JSON 动态解析出的结构体字段名、运行时才加载的插件类型
func Sum[T ~int | ~float64](a, b T) T {
return a + b
}
// 编译后生成 Sum[int] 和 Sum[float64] 两个独立函数，无反射逻辑
反射：运行时探查，灵活但有代价
反射基于 interface{} 底层的类型信息，在程序运行时通过 reflect.TypeOf 和 reflect.ValueOf 获取并操作值，适用于真正动态的场景。
- 能处理任意类型，包括未导出字段、嵌套结构、接口底层具体类型等
- 所有操作都在运行时完成：类型断言、字段遍历、方法调用都需
reflect包支持，带来明显性能损耗 - 容易 panic：如对 nil 指针调用
v.Elem()、对不可寻址值调用v.Set()、访问未导出字段等
v := reflect.ValueOf(struct{ Name string }{Name: "Alice"})
fmt.Println(v.Field(0).Interface()) // "Alice"
// 但如果字段是小写 name，则 v.Field(0).Interface() 会 panic：cannot interface with unexported field
什么时候该用泛型，什么时候必须用反射？
关键看「类型是否在编译期可知」以及「操作是否需要突破类型边界」。
立即学习“go语言免费学习笔记（深入）”；
- 用泛型：通用容器（
Stack[T]）、切片工具（Map[T, U]）、约束明确的校验（Equal[T comparable]） - 必须用反射：JSON/YAML 序列化、ORM 字段映射、结构体标签解析（如
json:"name"）、动态调用方法（v.MethodByName("Save").Call(...)） - 泛型 + 反射结合：泛型函数内部用反射做类型适配，例如
func Inspect[T any](t T) { tType := reflect.TypeOf(t) }—— 这样既保编译期类型入口，又留运行时探查能力
泛型无法绕过反射的典型坑
即使写了泛型，一旦涉及结构体字段级操作（如忽略某个字段、按 tag 提取值），仍逃不开反射。常见误判是以为加了 [T any] 就能避免 reflect。
- 泛型参数
T在函数体内仍是黑盒：你无法用len(T)或T.Name访问结构体字段，必须用reflect.ValueOf(t).NumField() - 泛型不解决「字段名动态化」问题：比如根据字符串
"Email"去取结构体对应字段，必须靠反射 - 反射在泛型中仍要手动处理：nil 检查、可寻址性、未导出字段跳过等逻辑一个都不能少，泛型不自动帮你兜底
真正复杂的通用库（如 validator、sqlx、mapstructure）都是泛型定义入口 + 反射实现核心，而不是二选一。
