不会直接阻止gc，但若addr()返回的reflect.value被长期持有（如存入全局map、闭包或channel），会因可达性分析使原对象无法回收。
reflect.Value.Addr() 会阻止 GC 吗？
不会直接阻止，但可能间接延长对象生命周期。Addr() 返回的是一个指向原值的 reflect.Value，它本身不持有堆上新分配的数据，但它包装的 word unsafe.Pointer 指向原始内存地址——如果这个地址属于堆上对象，且该 reflect.Value 被长期持有（比如塞进全局 map、闭包或 channel），Go 的可达性分析就会把它当作“根引用”的一部分，导致目标对象无法被回收。
常见误用场景：
- 把
reflect.Value.Addr()结果存进sync.Map或全局 slice，而原始 struct 实例早已超出作用域 - 在 HTTP handler 中对请求体做
reflect.ValueOf(&req).Elem().FieldByName("X").Addr()，然后把返回值传给后台 goroutine 处理——只要那个 goroutine 还活着，整个req就算没被显式引用也会被标记为存活 - 用
Addr()获取字段地址后调用UnsafeAddr()，再转成*int存起来：此时 GC 完全依赖你手动管理指针有效性，一旦原对象已回收，就是悬空指针
Addr() 和直接取地址（&v）性能差多少？
几乎没差别——Addr() 本身只是封装了 unsafe.Pointer 并构造一个新的 reflect.Value，不触发分配、不查方法表、不校验类型。它比 reflect.ValueOf(&x) 略轻量，因为后者要走完整 ValueOf 流程（包括类型检查、接口拆包、零值判断）。
但注意：只有可寻址（addressable）的 reflect.Value 才能调 Addr()，否则 panic。可寻址性取决于原始值是否在栈/堆上可取地址，而非是否导出。例如：
-
reflect.ValueOf(myStruct).Addr()→ panic: unaddressable -
reflect.ValueOf(&myStruct).Elem().Addr()→ OK，因为Elem()返回的是可寻址副本 -
reflect.ValueOf(struct{X int}{1}).Addr()→ panic，字面量不可寻址
为什么有时 Addr() 返回的 Value.Call 会 panic “call of reflect.Value.Call on zero Value”？
这不是 Addr() 的问题，而是你对返回值没做 IsValid() 检查就直接用了。典型链路是：v := reflect.ValueOf(&s).Elem().FieldByName("F"); if !v.IsValid() { ... } 漏掉这步，后续 v.Addr().Call(...) 就会崩。
更隐蔽的情况：字段名拼错、字段未导出、或结构体嵌套层级不对，都会让 FieldByName() 返回零值，而 Addr() 在零值上调用也会返回零值——但错误源头不在 Addr()，而在上游获取失败。
实操建议：
- 所有
FieldByName/MethodByName后必须紧跟if !v.IsValid() - 不要链式调用
.Addr().Call()，拆成两步并分别检查 - 若字段名固定，优先用
v.Field(i)避免字符串查找失败的静默零值
Addr() + Interface() 是不是双重开销？
是，而且很重。先 v.Addr() 得到指针型 reflect.Value，再 .Interface() 转成 interface{}，会触发两次接口转换和一次堆分配（因为 Interface() 必须返回可被 GC 跟踪的接口值）。尤其当目标类型是小 struct 或基础类型时，这种转换性价比极低。
替代方案：
- 如果只是为了传参给函数，直接用
reflect.Value.Addr().Interface()是最简路径，但仅限低频调用 - 高频场景（如序列化循环）应避免
Interface()，改用UnsafeAddr()+unsafe.Pointer强转，但需确保生命周期可控 - 真要通用，不如提前生成函数指针：
fn := func(p *MyStruct) { p.F = "x" }; reflect.ValueOf(fn).Call([]reflect.Value{v.Addr()})—— 这样省掉Interface()，且 fn 可缓存
最易被忽略的一点：哪怕你只调了一次 Addr()，只要返回的 reflect.Value 被赋给了包级变量或逃逸到堆上，它所引用的原始对象就可能被 GC 误判为“仍被活跃使用”。这不是 bug，是反射设计的必然代价——你拿到的不是快照，而是活引用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
