reflect.ValueOf传入指针返回的是指针的反射封装，非裸地址；其内部持有地址信息，但.Interface()返回*Type值，需v.Pointer()获取uintptr，且不保证GC安全。
reflect.ValueOf 对指针返回的是地址值还是指针包装？
直接说结论：reflect.ValueOf 传入指针变量时，返回的 Value 类型本身不等于内存地址，而是对指针的反射封装；它内部持有该指针的地址信息，但你不能直接用 .Interface() 拿到裸地址数字（比如 0xc000010230），除非显式取地址再转 uintptr。
常见错误现象：有人以为 reflect.ValueOf(&x).Interface() 就是地址，结果得到的是 *int 类型值，不是整数地址；或者想用 fmt.Printf("%p", v.Interface()) 打印却 panic：interface{} 不支持 %p 直接解包。
- 正确做法是先确认是否为指针类型：
v.Kind() == reflect.Ptr - 再用
v.Pointer()获取底层地址（返回uintptr） - 若需打印，用
fmt.Printf("%p", unsafe.Pointer(v.Pointer()))（注意要 importunsafe）
为什么 v.Addr() 在非地址able 的 Value 上 panic？
v.Addr() 不是“取地址”，而是“获取可寻址的反射对象的地址”——它要求原 Value 本身必须来自可寻址的变量（比如局部变量、结构体字段），而不是临时值或字面量。传入 reflect.ValueOf(42) 或 reflect.ValueOf(x)（x 是值拷贝）后调 .Addr() 必然 panic：reflect.Value.Addr of unaddressable value。
使用场景典型如：你想通过反射修改某个字段，就必须从可寻址对象开始（比如 &struct{}），否则所有 .Set* 方法都无效。
立即学习“go语言免费学习笔记（深入）”；
- 安全前提：确保原始值来自变量而非字面量，例如
var x int = 42; v := reflect.ValueOf(&x).Elem()→ 此时v可寻址 -
v.CanAddr()是判断依据，返回 true 才能调v.Addr() - 常见误操作：对函数返回值、map 查找结果、切片元素（未取地址）直接调
.Addr()
reflect.Value.Pointer() 和 unsafe.Pointer 的关系与风险
v.Pointer() 返回的是 uintptr，本质是内存地址数值；但它**不保证 GC 安全**——如果对应变量被回收，这个地址可能指向已释放内存。所以它只适合短期、受控场景（比如调试、序列化底层地址、FFI 交互），绝不能长期保存或跨 goroutine 使用。
性能影响几乎为零，但兼容性差：在 Go 1.22+ 中，某些构建模式（如 -gcflags="-d=checkptr"）会拦截非法 unsafe.Pointer 转换，导致运行时报错。
- 必须配合
unsafe.Pointer(uintptr)才能用于系统调用或 cgo - 禁止把
v.Pointer()存进 map 或全局变量中等待后续读取 - 若目标是跨函数传递地址，优先考虑传
*T或unsafe.Pointer显式参数，而非靠反射提取
想安全获取 struct 字段的内存偏移？别依赖 reflect.Value.Pointer()
很多人想用反射 + .Pointer() 算字段地址偏移，这是危险路径。因为 v.Field(i).Pointer() 返回的是字段所在结构体中的绝对地址，不是相对于结构体起始的 offset；而且一旦结构体被移动（比如切片扩容、GC 堆调整），该地址就失效。
真正需要偏移时，应该用 unsafe.Offsetof(T{}.Field) —— 它在编译期计算，稳定、零开销、无 GC 风险。
-
reflect.ValueOf(&s).Elem().Field(i).Pointer()得到的是运行时地址，不是偏移量 - 字段偏移和内存布局由编译器决定，
unsafe.Offsetof是唯一标准方式 - 如果字段是嵌入的或有 tag 影响对齐，
Offsetof仍准确，而反射地址无法反映这些细节
复杂点在于：反射地址和偏移量混用极易引发静默错误，尤其在结构体含指针或 sync 包类型时，GC 可能移动数据但不更新你缓存的 uintptr。这事容易被忽略，直到线上偶发 crash。
