反射性能差且易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 的源码里，而不是你的业务逻辑里。
