泛型解决编译期类型复用，反射解决运行时类型未知；泛型零开销但无法处理字段级动态操作，反射灵活却有性能损耗和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

什么时候该用泛型，什么时候必须用反射？

关键看「类型是否在编译期可知」以及「操作是否需要突破类型边界」。

• 用泛型：通用容器（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）都是泛型定义入口 + 反射实现核心，而不是二选一。