泛型不能取代反射，二者适用场景不同：泛型适用于编译期已知类型的通用逻辑，反射则用于运行时动态结构（如json解析、orm映射、yaml加载、校验框架、rpc反序列化）等必须依赖类型信息的场景。
泛型真能取代反射吗？看清楚“编译期可知”这个前提
不能。泛型不是反射的替代品，而是把原本必须靠反射做的“类型通用逻辑”，移到编译期去解决——前提是：你得在写代码时就知道可能用到哪些类型。
比如你要写一个切片去重函数，如果只处理 []string、[]int、[]UserID 这几类，且它们都满足 comparable，那 func Unique[T comparable](s []T) []T 就比用 reflect.ValueOf 遍历安全、快、可调试。
- 泛型函数调用时必须显式或推导出
T，比如Unique([]int{1,2,2})中T是int；而反射可以接收任意interface{}，连结构体字段名都不知道也照跑 - 泛型无法读取
json:"name"这种 struct tag，也不能通过字符串"CreatedAt"动态取字段——这些操作仍得靠reflect.StructTag.Get和v.FieldByName - 如果你的程序要加载用户上传的 YAML 文件，字段名和嵌套层级完全未知，泛型连函数签名都写不出来，反射是唯一路径
哪些地方反射还绕不开？盯紧这五个运行时动态场景
只要需求涉及「运行时才确定结构」，反射就仍是刚需。这不是性能妥协，而是能力边界问题。
-
json.Unmarshal内部必须用反射：输入是[]byte，输出目标类型只有运行时传入才知道，字段名、是否指针、是否忽略空值，全靠reflect.Type解析 tag - ORM 映射（如 GORM）需要把
type User struct { ID int `gorm:"primarykey"` }的 tag 和数据库列名对齐——泛型做不到按字符串匹配字段 - 配置加载（
viper.Unmarshal）要把 YAML 键db.host填进Config.DB.Host字段，字段路径是运行时解析的，不是编译期枚举的 - 通用校验框架扫描所有带
validate:"required"的字段并校验值，字段名、tag 内容、嵌套深度，全在运行时动态遍历 - RPC 服务端收到字节流后，得根据注册的类型名（如
"user.CreateReq"）动态构造结构体实例，再反序列化——类型名是字符串，不是 Go 类型
高频路径里滥用反射，性能会掉多狠？
在 HTTP handler 或消息循环里每请求都调一次 reflect.TypeOf 或 reflect.ValueOf，实测吞吐可能直接跌 50% 以上。这不是理论，是压测数据。
立即学习“go语言免费学习笔记（深入）”；
- 别在每次请求里做
v := reflect.ValueOf(req).NumField()，改在init()里缓存reflect.Type和字段索引映射，后续查表即可 - 自己手写 ORM 映射时，别每次
rows.Scan都重新v.FieldByName("Name")，应提前构建map[string]int（字段名→结构体字段序号）并复用 - 缓存要用
sync.Map，别用普通map[reflect.Type][]fieldInfo，否则并发写 panic - 漏掉指针解引用很常见：传入的是
*User，但忘了先v.Elem()就调v.NumField()，直接 panic
泛型+反射混合用，怎么避免掉坑？
最典型的场景是：泛型容器想加调试日志，或者泛型校验器想读 struct tag。这时候反射不是主角，只是配角——必须控制它的作用域和生命周期。
- 只在真正需要的分支触发反射，比如加个
if debug { log.Printf("%v", reflect.TypeOf(v)) }，别让反射逻辑混进主流程 - 用
v.Kind() == reflect.Struct先校验类型，再用v.Type().Name()确认是不是预期结构体，避免对int调v.Field(0) - 反射拿到的值，尽快转回具体类型：
val.Interface().(MyType)或val.Interface().(fmt.Stringer)，恢复编译期检查能力 - 缓存
reflect.Type结果，尤其在循环中重复调用reflect.TypeOf(x)是典型低效写法
reflect；如果不是，硬塞反射只会给自己埋雷。 
