Go反射什么时候不该用_Go反射使用边界说明

反射性能差且易panic，应避免在高频路径使用；必须用时需校验有效性、可设置性及类型匹配，优先选用编译期确定方案。

高频路径中调用 reflect.DeepEqual 或遍历字段

不该用——它比手写比较慢近40倍，且在GC敏感场景（如分钟级导出、实时日志聚合）会直接引发CPU

飙高和GC抖动。线上曾有服务因把报表导出从小时级改成分钟级，reflect.DeepEqual 在循环里被反复调用，10个节点中4台持续OOM。

• 替代方案：固定结构体就手写 == 比较逻辑，或用 jsoniter.ConfigFastest.Equal() 这类预生成的高效比较器
• 若必须动态比较，先用 v.Kind() 快速排除类型不匹配，避免进深层递归
• 永远不要在 for 循环内部无条件调用 reflect.ValueOf() —— 每次都触发内存分配和类型解析

修改变量时传入非指针或未检查 CanSet()

一写就 panic：reflect: reflect.Value.SetInt using unaddressable value。这不是 bug，是反射机制的硬性约束：只有可寻址（addressable）且可导出（exported）的值才能被修改。

• 必须传指针：reflect.ValueOf(&x)，再调 .Elem() 获取目标值
• 调 SetInt() 前务必检查：rv.Elem().CanSet() == true
• 结构体字段名首字母小写（如 name string）——反射能读，但 CanSet() 返回 false，强行 SetString() 会 panic

代替类型断言或泛型做简单分支判断

比如本可用 v, ok := data.(string) 或 Go 1.18+ 的 func[T any](v T) 解决的问题，却绕一圈用 reflect.TypeOf(v).Kind() == reflect.String —— 纯属自找麻烦。

• 编译期能确定的类型，绝不推到运行时；类型参数（generics）已覆盖绝大多数泛型容器/工具函数场景
• 反射无法做静态检查，Kind() 返回 reflect.String，不代表它真能当 string 用；后续 Interface() 转换失败仍会 panic
• 团队新成员看到 reflect.Value.Elem().FieldByName("ID").Interface().(int64) 这种链式调用，第一反应不是理解逻辑，而是查文档保命

处理 nil 接口或未初始化指针

reflect.ValueOf(nil) 返回的是零值 Value，其 Kind() 是 Invalid，后续任何 .Elem()、.Field() 都直接 panic。

• 安全访问前必判：if !rv.IsValid() { return } 或 if rv.Kind() == reflect.Ptr && rv.IsNil() { ... }
• 结构体字段为指针类型（如 Age *int）时，不能直接 field.Set(reflect.ValueOf(&newAge)) —— 要先 reflect.New(field.Type().Elem()) 分配内存
• 所有来自外部输入的 interface{}（如 HTTP body 解析结果），反射前先做非空校验，别信“它应该不为 nil”

反射真正的价值不在“能做什么”，而在“不得不做什么”：JSON 序列化、ORM 字段映射、插件系统动态加载——这些场景下它不可替代。但只要编译期能定死类型、结构或行为，就该让反射待在 encoding/json 的源码里，而不是你的业务逻辑里。