需传指针并调用Elem()确保可寻址和可设置，且必须用CanSet()检查；MethodByName后须验证IsValid()及接收者匹配；Int()等取值前需用Kind()或CanInt()预检；DeepEqual仅适用于测试等低频场景。
reflect.Value.Set panic: “using unaddressable value” 怎么修？
这是 Go 反射里最常触发的 panic，根本原因是：v.Set(...) 要求 v 必须可寻址（addressable）且可设置（settable）。直接对值类型调用 reflect.ValueOf(x) 得到的 Value 永远不可寻址。
- ❌ 错误写法：
var x int = 10 v := reflect.ValueOf(x) v.SetInt(20) // panic: reflect: reflect.Value.SetInt using unaddressable value
- ✅ 正确写法：必须传指针，再调用
Elem()：var x int = 10 v := reflect.ValueOf(&x).Elem() if v.CanSet() { v.SetInt(20) } fmt.Println(x) // 输出: 20 - ⚠️ 注意：即使传了指针，也要检查
v.CanSet()—— 比如对字符串字面量"hello"取地址后Elem()，依然不可设（因为底层是只读内存） - ⚠️ 结构体字段同理：未导出字段（小写首字母）即使可寻址，
CanSet()也返回false，强行Set会 panic
MethodByName 调用失败却不报错？怎么安全判断？
reflect.Type.MethodByName() 和 reflect.Value.MethodByName() 都不会 panic，而是返回无效的 reflect.Value。如果你没检查有效性就直接 Call()，会在运行时 panic，堆栈难以定位。
- ❌ 危险写法：
sfunc := stype.MethodByName("Save") ret := sfunc.Call([]reflect.Value{...}) // 若 sfunc 无效，这里 panic - ✅ 必须验证三件事：
– 方法是否存在：if !sfunc.IsValid()
– 接收者是否匹配：若方法定义在*MyStruct上，你传的是MyStruct{}值，则IsValid()为false
– 返回值数量和类型：调用后先检查len(ret) >= 1，再确认最后一个是否是error类型（别直接ret[1].Interface().(error)，可能 panic） - ? 小技巧：用
reflect.ValueOf(obj).MethodByName("X").IsValid()比查reflect.TypeOf(obj).MethodByName("X")更可靠，因为它同时校验了接收者类型兼容性
Int()/String()/Float() 等取值方法为什么突然 panic？
这些方法不是“尽力而为”，而是强契约：调用 v.Int() 前，v.Kind() 必须是 reflect.Int（或其变体如 Int32），否则直接 panic —— 不会返回零值或错误。
- ❌ 典型翻车：
var f float64 = 3.14 v := reflect.ValueOf(f) fmt.Println(v.Int()) // panic: reflect: call of reflect.Value.Int on float64 Value
- ✅ 安全姿势：
– 先用v.Kind()或v.Type()判断类型：if v.Kind() == reflect.Int { ... }
– 或用CanInt()/CanFloat()等谓词方法预检：if v.CanInt() { n := v.Int() }
– 转换需求强烈时，用CanConvert()+Convert()，比如把int64安全转成int - ⚠️ 特别注意：
Interface()也不安全！如果v是不可寻址的未导出字段，Interface()会 panic，要用CanInterface()先兜底
为什么 reflect.DeepEqual 比手写比较慢 40 倍？
它确实方便，但代价明确：递归遍历所有字段、动态 dispatch 类型逻辑、处理切片/映射/接口等复杂结构 —— 这些全是运行时开销。基准测试显示，对中等结构体，reflect.DeepEqual 比手动逐字段比较慢近 40 倍。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 合理用法：
– 测试断言（如assert.Equal(t, want, got)底层常用它）
– 配置热重载时做 deep diff
– 你无法提前知道结构体字段（ORM 映射、通用缓存键生成） - ❌ 滥用场景：
– HTTP handler 内高频调用（如鉴权时比用户 session）
– 循环内调用（哪怕只是日志打点）
– 已知结构简单，却仍用反射兜底 - ? 替代方案：
– 为关键结构体实现Equal(other T) bool方法（零分配、编译期优化）
– 用go:generate自动生成比较函数（如 cmp 或 go-diff）
– 缓存reflect.Type和字段信息，避免重复反射解析
反射不是魔法棒，它是把双刃剑：每一步操作都依赖运行时状态，而这些状态（可寻址性、导出性、方法存在性、类型匹配）全得你自己手动守门。不验证就调用，等于在代码里埋雷——表面安静，一触即爆。
