反射访问指针字段比值字段慢，因每次解引用需额外 reflect.value 构造、nil 检查及 elem() 调用，json 编码中该开销致性能下降 15–25%。
反射访问指针字段比值字段慢，不是因为指针本身，而是因为每次解引用都触发额外的 reflect.Value 构造和 nil 检查。
FieldByName 访问指针字段时会多一次 Elem() 调用
当你对结构体字段做 reflect.Value.FieldByName("Field")，如果该字段类型是 *string，返回的 reflect.Value 的 Kind() 是 reflect.Ptr；而 string 字段返回的是 reflect.String。这意味着后续想读写值时，指针字段必须显式调用 .Elem() 才能拿到真实值——这步不是免费的：
-
.Elem()内部会检查IsNil()，涉及一次分支判断和指针有效性校验 - 每次调用都新建一个
reflect.Value实例，带来堆分配（哪怕只是小结构体） - 若忘记判 nil 就调
.Elem()，运行时 panic，调试成本高
对比直接访问值类型字段：一次 FieldByName + 直接 .String() 或 .SetString()，无额外跳转、无额外分配、无 panic 风险。
JSON 编码中指针字段拖慢性能的真实原因
encoding/json 对 *string 字段的处理流程是：ValueOf(field).Elem().Interface() → 再走一遍反射取值 → 最终才交给底层 encoder。这个链条里至少新增两次 reflect.Value 构造和一次 Elem()。实测显示，在 10k 级别结构体 JSON 序列化中，全用指针字段比全用值字段慢 15–25%，主要开销就卡在这几步。
- 值字段：字段值直出，
json包可内联优化部分路径 - 指针字段：强制绕进
reflect.Value.Elem().Interface()，禁用编译器内联，且每次都要重新查类型元数据 - 空指针（
nil）还会触发额外的omitempty判断逻辑，进一步放大差异
缓存无法消除指针字段的反射开销
你可能想到缓存字段索引或 reflect.Type 来提速，但这对指针字段效果有限：
- 缓存
reflect.StructField或字段索引（Field(i)）只能省掉FieldByName的字符串查找，但.Elem()这步仍得每次执行 - 无法缓存
reflect.Value.Elem()的结果，因为reflect.Value绑定具体实例，不可复用 - 想彻底避开，得生成闭包：预计算
unsafe.Offsetof(Struct{}.PtrField)，再封装为func(v interface{}) *string，但这就脱离了“纯反射”范畴
换句话说：缓存能把你从 O(n) 拉到 O(1) 的字符串匹配，但消不掉指针字段固有的 O(1) 额外反射跳转。
什么时候该用指针字段，什么时候不该
别为了“避免拷贝”盲目用指针字段——Go 的结构体传参默认是值拷贝，但小字段（int、string、time.Time）本身就很轻；而反射访问指针字段带来的运行时开销，往往比拷贝还重。
- 适合用指针：大 slice/map/struct（>64B）、需区分零值与未设置（如 API 请求参数）
- 不适合用指针：小字段（
int64、bool、短string）、高频反射场景（ORM Scan、JSON 编解码） - 更优替代：用值类型 + 自定义
UnmarshalJSON控制零值逻辑，既免反射又保语义
真正容易被忽略的点是：**指针字段在反射路径上引入的是“固定开销”，它不随数据量增长，但随调用频次线性放大——一个每秒处理 10k 请求的 HTTP handler，哪怕只反射读一个 *string 字段，也足以让 P99 延迟上浮 0.5ms 以上。**
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
