Go反射不支持自动深层对象映射，需手动处理字段拷贝、类型转换和嵌套；reflect.Value.Set()报“cannot set”因值不可寻址或不可设置，须确保传地址或局部变量；字段名不一致需解析struct tag并fallback匹配；递归映射需用指针地址缓存防循环引用；性能差5–20倍，应优先代码生成或缓存Type/字段索引。
Go 的反射无法自动完成“对象到对象”的深层映射，reflect 本身不提供类似 Java BeanUtils 或 Python attrs 的声明式映射能力；所有字段级拷贝、类型转换、嵌套处理都得手动控制逻辑。
为什么 reflect.Value.Set() 常报 “cannot set” 错误
这是最常卡住的地方：反射值必须是可寻址（addressable）且可设置（settable）的，否则 Set() 直接 panic。
- 传入函数的参数默认是值拷贝，
reflect.ValueOf(obj)得到的是不可寻址副本 → 必须用reflect.ValueOf(&obj).Elem() - 从 map 或 slice 中取出来的元素（如
m["key"]）也是不可寻址的 → 需先赋值给局部变量再取地址 - 接口类型（
interface{}）底层值若为不可寻址类型（如字面量42、"hello"），也无法 Set
示例修复：
func copyField(dst, src reflect.Value) {
if !dst.CanAddr() || !dst.CanSet() {
return // 跳过不可设置字段
}
if src.Kind() == reflect.Ptr && !src.IsNil() {
src = src.Elem()
}
if src.Type() == dst.Type() {
dst.Set(src)
}
}
如何安全处理结构体字段名不一致（如 JSON tag 映射）
反射本身不读 tag，但可通过 reflect.StructField.Tag.Get("json") 拿到标签值，再手动匹配源字段。关键在于：别硬编码字符串比较，要统一提取目标字段名。
立即学习“go语言免费学习笔记（深入）”；
- 目标结构体字段应有
json:"user_name"，源结构体字段名可能是UserName或UserName+json:"user_name" - 遍历目标字段时，先查
dstField.Tag.Get("json")，若为空则 fallback 到dstField.Name - 源字段查找也按同样规则：优先 match tag，再 fallback 到首字母小写名（
strings.ToLower(dstField.Name[:1]) + dstField.Name[1:]） - 注意：tag 值可能含选项，如
json:"user_name,omitempty"，要用strings.SplitN(tag, ",", 2)[0]提取主键
嵌套结构体与切片的递归映射怎么避免无限循环
一旦字段类型是 struct 或 []T，就需递归调用映射函数 —— 但 Go 反射没有内置“已处理类型缓存”，容易在循环引用（如 A→B→A）或自引用（type Node struct { Parent *Node }）时栈溢出。
- 必须传入一个
map[uintptr]bool记录已进入的结构体指针地址（value.UnsafeAddr()），每次递归前检查是否已存在 - 对切片，只递归元素类型，不递归切片头本身；但要注意
nilslice 和空 slice 的区别：src.Len() == 0不代表是nil，需用src.IsNil() - 不要无条件递归 interface{}：它可能包装任意类型，包括 func、map、chan —— 这些类型不能 Set，也不该被映射
性能敏感场景下，反射映射是否值得用
实测表明，纯反射映射比手写字段赋值慢 5–20 倍，GC 压力明显上升；尤其在高频调用（如 HTTP 请求绑定）中，开销不可忽视。
- 若字段数固定、结构稳定，优先用代码生成（
go:generate+stringer类工具）生成专用映射函数 - 若必须运行时动态映射，至少缓存
reflect.Type和字段索引（fieldCache[reflect.Type] = []int），避免重复NumField()和Field()调用 - 对简单平铺结构（无嵌套、无指针、字段名完全一致），可考虑用
unsafe+ 内存拷贝（仅限同内存布局类型），但失去类型安全
真正难的不是“怎么用反射”，而是判断哪些字段该跳过、哪些类型该降级为零值、以及当源字段缺失时要不要清空目标字段 —— 这些逻辑反射帮不了你，得靠业务规则兜底。
