泛型与反射是分层协作关系：泛型限定编译期类型边界，反射处理运行时结构未知场景；关键结合点为“泛型收口、反射破界”，用于字段操作、方法调用、配置绑定等需类型安全与动态性的场合。
泛型和反射在 Go 中不是替代关系，而是分层协作关系：泛型解决编译期可表达的通用逻辑，反射补足编译期无法获知结构的运行时场景。二者结合的关键点在于——用泛型收口、用反射破界。
泛型函数里嵌入反射做类型安全的结构体字段操作
当你需要一个能处理任意结构体但又必须保证字段名存在、类型匹配、可导出的通用赋值函数时，单纯泛型无法校验字段是否存在，单纯反射又丢失类型约束。这时用泛型限定输入类型，再用反射完成字段级操作：
- 泛型参数
T确保编译期知道结构体类型，避免interface{}导致的运行时 panic - 函数内部调用
reflect.TypeOf((*T)(nil)).Elem()获取结构体Type，再通过FieldByName查字段，比对CanSet()和CanInterface() - 字段类型不匹配时，
reflect.Value.Set()会直接 panic，而泛型签名已提前排除了非结构体类型，缩小了错误范围
示例中常见错误：传入指针却忘记 .Elem()；或传入非导出字段名导致 FieldByName 返回零值 Value，后续 .Set() panic。
反射调用方法前用泛型约束 receiver 类型
动态调用方法（如插件系统、命令路由）常需 MethodByName，但若 receiver 是 interface{}，反射无法判断方法是否真的存在且可调用。用泛型提前约束 receiver 必须实现某接口，再用反射调用具体方法名，兼顾灵活性与安全性：
立即学习“go语言免费学习笔记（深入）”；
- 定义泛型函数
func CallMethod[T interface{ SomeInterface }](t T, name string, args ...interface{}) - 内部用
reflect.ValueOf(t).MethodByName(name)，此时t已是具体类型，反射能正确解析方法集 - 若
name不存在，MethodByName返回无效Value，可提前返回错误；而泛型约束确保t至少实现了基础行为契约
容易踩的坑：reflect.ValueOf(&t).MethodByName 会尝试在指针上调用方法，结果是空的；必须传值或确认 receiver 方法集是否包含指针接收者。
配置绑定时泛型提供目标类型，反射完成字段映射
YAML/TOML 解析到 struct 的过程，本质是「已知目标类型 + 未知键值对」的映射。泛型让绑定函数支持任意 struct，反射负责把 map[string]interface{} 中的键按 tag 或字段名填入对应字段：
- 函数签名如
func BindConfig[T any](data map[string]interface{}) (T, error)，T是目标结构体类型 - 内部用
reflect.New(reflect.TypeOf((*T)(nil)).Elem()).Interface()创建可寻址实例 - 遍历
data键，用reflect.Value.FieldByName或Tag.Get("yaml")匹配字段，再根据Kind()调用SetString/SetInt等
性能影响明显：每次调用都新建 reflect.Type 和 reflect.Value，应缓存 reflect.Type 和字段索引映射表；否则高频配置热更新时 GC 压力陡增。
真正需要二者结合的地方，往往卡在「编译期类型已知但结构未知」这个缝隙里——比如 ORM 映射器既要接受任意 Customer、Order，又要根据 gorm:"column:xxx" 标签生成 SQL 字段。这时候泛型收住类型边界，反射钻进结构内部，缺一不可。但一旦泛型能覆盖（如只处理 []string、map[string]int），就别碰反射。
