UnsafeAddr()仅对可寻址reflect.Value有效，否则panic；它不延长变量生命周期，易致悬垂指针；性能不优于缓存字段索引，且叠加类型、内存、GC三重风险。
直接用反射获取底层指针（比如 reflect.Value.UnsafeAddr()）不是“能不能”的问题，而是“值不值得冒这个险”的问题——它既容易触发 panic，又无法规避 GC 陷阱，且性能并不比缓存字段索引更好。
为什么 UnsafeAddr() 会 panic：可寻址性不是默认属性
UnsafeAddr() 只对可寻址（addressable）的 reflect.Value 有效，而绝大多数反射值默认不可寻址。常见错误包括：
- 对传入的值本身调用：
reflect.ValueOf(x).UnsafeAddr()→ panic “cannot call UnsafeAddr on unaddressable value” - 对 interface{} 值解包后未取地址：
v := reflect.ValueOf(&someStruct).Elem(); v.Field(0).UnsafeAddr()如果该字段是未导出（小写）或嵌套在不可寻址结构中，仍会失败 - 对 slice/string header 调用：
reflect.ValueOf(mySlice).UnsafeAddr()返回的是 slice header 地址，不是底层数组起始地址；误用会导致越界读写
必须先确认 v.CanAddr() == true，且该值来自显式取址（&x）或 reflect.New() 创建。
UnsafeAddr() + unsafe.Pointer 的 GC 生命周期陷阱
反射对象本身不延长底层变量的生命周期。一旦原始变量栈帧退出或被 GC 回收，unsafe.Pointer 就变成悬垂指针：
立即学习“go语言免费学习笔记（深入）”；
- 错误模式：
ptr := uintptr(v.UnsafeAddr()); runtime.GC(); *(*int)(unsafe.Pointer(ptr))→ 可能访问已释放内存 - 正确做法：所有指针运算必须“一气呵成”，即
unsafe.Pointer(ptr + offset)必须在单条表达式中完成并立即用于读写；若需跨函数传递，必须保留一个合法 Go 指针（如原结构体指针）并配合runtime.KeepAlive() - 特别注意：从
reflect.Value构造的unsafe.Pointer不能存储为全局变量或 map value，否则 GC 无法追踪其引用关系
性能上，UnsafeAddr() 并不比缓存字段索引快
很多人以为绕过反射字段查找就能提速，但实测表明：v.Field(i).UnsafeAddr() 的开销和 v.Field(i).Interface() 差距极小，真正瓶颈在反射值构造和字段遍历本身：
-
FieldByName("Name")是线性遍历，100 字段平均查 50 次；而Field(2)直接索引，快 3–5 倍且无分配 -
UnsafeAddr()只是返回地址，后续仍要手动计算偏移、类型转换、解引用——这些操作在 Go 1.21+ 中还增加了额外运行时检查 - 若目标只是读字段，用缓存后的
func(interface{}) interface{}闭包（预生成 getter）零反射、零逃逸，比任何UnsafeAddr()组合都稳定
真正安全的替代路径：什么时候该放弃 UnsafeAddr()
除非你正在写零拷贝序列化器、自定义 sync.Pool 或 syscall 封装器，否则大多数业务场景下应主动避开 UnsafeAddr()：
- 字段读写优先用缓存
Field(i)+SetXxx()，而非UnsafeAddr()+ 手动内存操作 - 字符串切片底层指针：改用
unsafe.String(unsafe.Slice(...))（Go 1.17+），禁用reflect.StringHeader构造 - 结构体字段批量访问：用
unsafe.Offsetof配合原始结构体指针计算偏移，不依赖reflect.Value中转 - 若必须用
UnsafeAddr()，只限于v.CanAddr() && v.Kind() == reflect.Struct || reflect.Array场景，且全程控制变量生命周期
最常被忽略的一点：反射本身已经让代码脱离编译期保障，再叠加 UnsafeAddr()，等于同时放弃类型安全、内存安全和 GC 安全——三重风险叠加，调试成本远超性能收益。
