reflect.value.set panic最常见原因是目标值不可寻址；必须确保传入指针并调用elem()，且字段可导出、非字面量、非零值（需用reflect.new而非reflect.zero），同时注意循环引用检测和缓存type提升性能。
reflect.Value.Set 为什么一调就 panic
最常见原因是目标值不可寻址：reflect.Value.Set 要求接收方是可设置的（CanSet() == true），而直接传入结构体字面量或非指针值时，reflect.ValueOf(src) 返回的是不可寻址副本。比如 CopyStruct(src, dst) 中若 dst 是值类型而非指针，reflect.ValueOf(dst).Field(i) 就无法 Set。
必须确保目标是地址：reflect.ValueOf(&dst).Elem()，且该值本身支持寻址（不能是常量、字面量、未导出字段所在结构体等）。
- 未导出字段永远无法写入，反射会静默跳过或 panic，取决于访问方式
-
reflect.Zero(t)返回不可寻址零值，不能直接Set；得用reflect.New(t).Elem()构造可寻址副本 - 切片、map、指针等引用类型，必须先
reflect.MakeSlice/reflect.MakeMap/reflect.New分配内存，再逐项填充
循环引用检测不加，深拷贝大概率卡死
递归拷贝结构体字段时，若两个结构体互相持有对方指针（如树节点父子双向引用、ORM 模型关联），不加防护会无限递归，最终栈溢出或 goroutine 阻塞。Go 反射本身不提供循环检测机制。
可靠做法是维护一个 map[uintptr]bool 记录已访问对象地址：v.UnsafeAddr() 获取地址前，先 v.CanAddr() 判断是否合法；对每个进入递归的值（结构体、指针、切片、map）都做此检查。
- 不能用
map[reflect.Value]bool—— 同一底层对象多次reflect.ValueOf()生成不同实例，键无法命中 - nil 指针、空切片、空 map 不调
UnsafeAddr()，否则 panic - interface{} 类型需先
v.Elem()取出动态值，再判断是否可寻址和是否已访问
缓存 reflect.Type 和字段索引能省掉 90% 开销
每次调用 reflect.Value.FieldByName("Name") 都要线性遍历所有字段名字符串匹配，O(n)；而首次解析 reflect.TypeOf(&v).Elem() 后，把字段名→索引映射存下来，后续直接 v.Field(index)，就是 O(1) 数组访问。
缓存粒度只到 reflect.Type 级别即可，reflect.Value 实例绝不缓存——它绑定具体值，无复用价值。
- 用
sync.Map存reflect.Type → []int（字段索引数组）或map[string]int（字段名到索引） - 字段信息里建议预存是否可设置、json tag 解析结果，避免每次重复解析
- 初始化阶段批量预热常用类型的缓存，防止首请求延迟抖动
真正高频路径上，该放弃反射就放弃
如果深拷贝发生在 HTTP 解码、DB 扫描、gRPC 序列化等每秒数千次的路径上，哪怕你把反射优化到极致，单次 reflect.Value.Call 或 FieldByName 仍稳定在 100–500ns，累积起来就是毫秒级开销。
这时应切到编译期方案：go:generate 为固定结构体生成专用拷贝函数，或用泛型约束入口，只在 fallback 场景走反射。
- 例如
type User struct { ID int `json:"id"` }，生成func CopyUser(src *User) *User，全程无接口分配、无字符串查找、无运行时类型检查 - 泛型函数如
func DeepCopy[T Copyable](src T) T，其中Copyable是自定义接口，手动实现类型专属逻辑，反射只用于兜底未知类型 - 警惕看似没反射的库：比如
encoding/json默认路径重度依赖反射，fmt.Printf("%+v")同样会触发完整反射遍历
循环引用检测和可寻址性校验这两步，漏掉任意一个，问题不会立刻暴露，而是在某个特定数据组合下静默卡死或 panic，排查成本远高于写的时候多加两行判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
