Go中90%的反射场景可用接口、泛型或类型断言替代；reflect会绕过编译检查、降低性能、增加调试难度，应优先使用json.Marshal/Unmarshal等封装好的方案，并谨慎校验reflect.Value有效性、缓存Type/Value、避免泛型与反射不当混用。
反射前先问：这真的需要 reflect 吗？
90% 的所谓“需要反射”的场景，其实可以用接口、泛型或简单类型断言替代。Go 的设计哲学是显式优于隐式，reflect 会绕过编译期检查、拖慢性能、增加调试难度。比如序列化/反序列化，优先用 json.Marshal / json.Unmarshal（它们内部用反射，但你不用写）；字段遍历需求，先考虑是否能定义统一接口如 Validator 或用泛型约束。
reflect.ValueOf(x).Interface() 容易 panic，必须检查有效性
常见错误是直接对 nil 指针、未导出字段或空 interface{} 调用 .Interface()，结果 runtime panic。正确做法是逐层校验：
val := reflect.ValueOf(x)
if !val.IsValid() {
return errors.New("invalid value")
}
if val.Kind() == reflect.Ptr && val.IsNil() {
return errors.New("nil pointer")
}
// 只有这时才安全调用 Interface()
data := val.Interface()
特别注意：从 struct 字段取值时，val.Field(i) 返回的 Value 可能不可寻址或不可导出——必须用 CanInterface() 判断能否转回 Go 值。
避免在热路径中反复调用 reflect.TypeOf 和 reflect.ValueOf
这两个函数开销不小，尤其在循环或高频函数中。如果类型固定（比如只处理 *User），应提前缓存 reflect.Type 和零值 reflect.Value：
立即学习“go语言免费学习笔记（深入）”；
var (
userType = reflect.TypeOf((*User)(nil)).Elem() // 缓存 *User 的元素类型
userZero = reflect.Zero(userType)
)
后续直接复用 userType 做 Kind()、NumField() 等判断，比每次 reflect.TypeOf(v) 快 3–5 倍。泛型普及后，这类缓存更应被 type Parameter[T any] 替代。
用泛型 + 反射混合时，别让 any 泄露到反射外层
泛型函数里混用反射，容易写出类型不安全的代码。例如：
func Process[T any](v T) {
rv := reflect.ValueOf(v)
// ❌ 错误：把 rv.Interface() 强转回 T，可能丢失泛型约束
raw := rv.Interface().(T) // panic if v is interface{} or wrong type
}
正确方式是用泛型参数约束反射行为，或完全交由反射处理：
func Process[T any](v T) {
rv := reflect.ValueOf(v)
// ✅ 安全：只用反射做通用操作，不反向 cast
if rv.Kind() == reflect.Struct {
for i := 0; i < rv.NumField(); i++ {
field := rv.Field(i)
if field.CanInterface() {
// 处理 field.Interface()
}
}
}
}
真正难维护的不是反射本身，而是把反射逻辑和业务逻辑耦合在同一个函数里——一旦要加日志、加权限校验、改字段名，就得同时改反射路径和业务分支。
