泛型适用于编译期已知类型的场景，反射适用于运行时类型未知的场景；泛型更安全高效，反射用于动态结构探查，二者可协作但不可替代。
泛型是编译期的事，反射是运行时的事——选哪个，取决于你写代码时知不知道类型。
什么时候必须用 reflect，泛型完全没用
当你面对的数据结构在编译期根本不存在：比如用户上传一个 JSON 文件，字段名是随机的；又或者配置文件里嵌套了 N 层 map，键名只有运行时才确定；再比如 ORM 要根据 struct 的 json: 或 db: tag 自动映射字段——这些场景下，泛型连类型参数都无从写起，reflect 是唯一选择。
- 泛型函数签名必须显式写出类型参数，如
func Parse[T User](data []byte)，但你根本不知道T是什么 -
reflect可以处理interface{}，而泛型不能绕过类型约束去操作字段名、tag、偏移量 - 像
json.Unmarshal这种底层逻辑，必须靠reflect.Value.FieldByName和reflect.StructTag才能工作
什么时候该用泛型，而不是硬套 reflect
如果你只是想让同一段逻辑适配 int、string、time.Time 等已知类型，那泛型更安全、更快、IDE 支持更好。
- 泛型函数调用不触发任何反射开销，
Sum[int]和Sum[float64]是两份独立机器码 - 类型错误在编译时报出，比如把
string传给要求comparable的泛型函数，Go 直接报错，不会等到上线后 panic - 别为了“通用”滥用反射写
IsIn或Map，现在用泛型几行就搞定：func Map[T, U any](s []T, f func(T) U) []U
泛型函数里调用 reflect 不是 bug，而是合理分层
泛型负责收口类型安全，反射负责探查结构细节——两者不是非此即彼，而是各干各的活。
立即学习“go语言免费学习笔记（深入）”；
- 比如写一个通用校验器：
func Validate[T any](v T) error，函数签名用泛型保证调用安全，内部用reflect.ValueOf(v)扫描字段和validate:tag - 注意别在高频路径里无条件触发反射，加个
if reflect.TypeOf(v).Kind() == reflect.Struct再进分支 - 反射拿到的
reflect.Value.Interface()返回的是interface{}，类型信息丢失，后续若需方法调用，得立刻断言回具体类型或接口
reflect 不能替代接口，也替代不了泛型的编译期保障
接口是静态契约，泛型是编译期特化，反射是运行时探查——三者定位不同。拿反射去模拟多态，往往换来的是性能损耗、panic 风险和 IDE 失效。
- 业务逻辑中优先用接口，比如
type Storer interface { Save() error }，比用反射调Save方法安全得多 - 泛型无法生成新类型，反射也无法绕过导出规则访问小写字段——Go 的克制设计意味着你没法靠它们实现 Java 那种动态代理或注解处理器
- 真正难的不是语法怎么写，而是判断：这个需求，到底是“编译期可穷举”，还是“必须等数据进来才知道”？前者交给泛型或接口，后者才轮到
reflect
容易被忽略的一点是：泛型函数内部调用 reflect.TypeOf 并不会让整个函数变成“反射函数”，它只是在需要动态分析结构时打开一扇小窗；但窗口开得太多、太宽，比如在循环里反复调用 reflect.ValueOf，性能就会明显掉下去。
