传指针更快是因为只有可寻址的reflect.value才能执行elem()、field()、call()等操作，传值会panic且修改无效；表面多一次解引用，实则避免重复校验与分配。
反射中对指针类型的间接引用本身不额外拖慢性能，真正吃掉 CPU 的是每次调用 reflect.ValueOf 和后续 Field/Call 时重复做的可寻址性校验、类型匹配与临时对象分配。
为什么传 &v 比传 v 多一层解引用，却反而更快？
表面上看，reflect.ValueOf(&v) 多了一次取地址和指针解引用，但实际收益远大于这点开销：只有可寻址的 reflect.Value 才能调用 Elem()、Field() 或 Call()；传值类型（如 struct{}）会直接 panic “call of reflect.Value.Call on zero Value”；reflect.ValueOf(v) 返回的是不可寻址副本，所有修改类操作（Set*、Call）全部失效；而 reflect.ValueOf(&v).Elem() 得到的才是原结构体的可寻址视图，后续字段访问可复用同一底层内存布局。
reflect.ValueOf(&v).Elem() 的三重隐性开销
这行代码看着简单，实则触发三次关键运行时动作：
-
reflect.ValueOf(&v)：查全局类型表、接口装箱、分配reflect.Value结构体（含标志位、类型指针、数据指针） -
.Elem()：校验是否为指针类型、检查是否为 nil、构造新reflect.Value并复制元信息 - 返回值若立即用于
Field(i)或MethodByName，又触发新一轮字段遍历或方法表查找
这些步骤无法内联，且每一步都绕过逃逸分析优化。实测在热路径中反复执行该链式调用，单次耗时可达 150–300 ns，而直接 v.Name 仅需 1–2 ns。
缓存 reflect.Type 和字段偏移，跳过 Elem() 链式调用
真正有效的优化不是“少写一次 .Elem()”，而是把整个链路提前折算成纯指针运算：
- 用
reflect.TypeOf(&v).Elem()在初始化阶段拿到结构体类型t，再用t.Field(0).Offset算出字段相对于结构体起始地址的偏移量 - 运行时直接用
unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)取值，完全避开reflect.Value构造 - 若需支持多种类型，缓存 key 必须用
uintptr(unsafe.Pointer(t))，而非t.String()（匿名 struct 会失效） - 不要缓存
reflect.ValueOf(&v).Elem()的结果——它绑定了具体变量地址，无法复用
最容易被忽略的间接引用陷阱
很多人以为只要传了指针就安全了，但以下情况仍会触发隐性间接引用并放大开销：
- 对
interface{}值做reflect.ValueOf：若底层是*T，.Elem()后还得再.Elem()一次才能到T，多一层跳转 - 嵌套指针（如
**T）未做足够.Elem()层级，导致后续Field()操作 panic - 字段本身是指针类型（如
Name *string），用v.Field(i).Interface()会触发额外接口转换和堆分配 - 在 HTTP handler 中对每个请求都执行
reflect.ValueOf(r).FieldByName("URL")：看似只查一次，实则每次都在做字符串线性匹配 + 类型查找 + 分配
真正的瓶颈从来不在“指针多解了一次”，而在于你让反射在不该出现的地方，一遍遍重做编译期早该确定的事。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
