反射仅适用于运行时才知类型信息的场景，误用会导致性能下降、维护困难和panic；调用前须检查可寻址性与可设置性，参数返回值需严格匹配，性能敏感路径应避免反射。
反射不是万能的动态开关，它只在类型信息必须延迟到运行时才可知的场景下成立；用错地方反而让代码更难维护、更慢、更容易 panic。
reflect.Value.Call 调用方法前必须检查接收者是否可寻址
直接对结构体字面量或值类型变量调用指针接收者方法会 panic：「call of reflect.Value.Call on zero Value」或「value is not addressable」。
- 必须传入
&structVar，再用reflect.ValueOf(&structVar).Elem()获取可寻址的Value - 调用前务必检查
v.CanAddr() && v.CanInterface()，否则Call会直接崩溃 - 如果方法是值接收者（如
func (u User) GetName()），传reflect.ValueOf(u)即可，但注意该值不可被修改 - 参数列表必须严格匹配签名：
[]reflect.Value中每个元素的Kind()和原始类型一致，比如int64不能直接传int
reflect.MakeFunc 动态生成函数时，桥接函数必须处理所有参数和返回值
reflect.MakeFunc 不是语法糖，它生成的是一个全新函数对象，桥接函数里漏掉任何一个参数或返回值，运行时就会 panic 或返回零值。
- 桥接函数签名必须是
func([]reflect.Value) []reflect.Value，不能省略results返回 - 参数解包需逐个判断
Kind()并调用对应取值方法：args[0].Int()、args[1].String()、args[2].Interface()等 - 返回值数组长度必须与函数声明的返回数量一致；若函数返回
(int, error)，就必须返回[]reflect.Value{reflect.ValueOf(n), reflect.ValueOf(err)} - 生成的函数无法被
go vet检查，类型错误只能在运行时暴露
修改字段值前必须确认 CanSet()，且字段必须导出
即使你拿到结构体指针的 reflect.Value，也不能随意改字段 —— Go 的反射遵循和普通代码一样的可见性规则。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
- 字段名首字母小写（如
name string）无法通过反射修改，v.FieldByName("name").CanSet()永远返回false - 必须先用
reflect.ValueOf(&obj).Elem()得到可寻址的结构体值，再用FieldByName或Field(i)获取字段 -
CanSet()为true是调用SetXxx()的前提，否则 panic：「cannot set unaddressable value」 - 对嵌套结构体字段（如
user.Profile.Age），要逐层调用FieldByName并确保每一层都可寻址
性能敏感路径上避免反射，尤其是高频循环或 HTTP handler 内
反射操作比原生访问慢 10–50 倍不是夸张 —— 它绕过了编译器优化，每一步都要查类型表、做安全检查、分配临时 reflect.Value。
- 不要在
for range循环里反复调用reflect.TypeOf(x)或reflect.ValueOf(x)；提前缓存Type和Value - HTTP handler 中解析 JSON 到结构体应优先用
json.Unmarshal（它内部已做反射缓存），而不是自己手写反射赋值逻辑 - ORM 字段映射等框架层，应使用
sync.Map缓存reflect.StructField切片和reflect.Type到字段偏移的映射，避免每次新建 - 一旦发现 pprof 显示
reflect.Value.Call或reflect.Value.Field占 CPU 高峰，说明反射已成瓶颈，应回退到代码生成（如go:generate）或泛型替代
真正难的不是写出能跑的反射代码，而是判断「这里到底需不需要反射」—— 类型确定、结构固定、性能关键的地方，硬编码永远比 reflect.ValueOf 更可靠、更快、更易 debug。
