StructField.Index长度本身无性能开销，真正耗时在于FieldByIndex每层调用均新建reflect.Value、执行类型检查与可寻址性校验，并触发runtime.reflectvaluecall汇编跳转。
StructField.Index 长度本身几乎不产生性能开销，真正影响性能的是 FieldByIndex 的递归访问深度和中间 reflect.Value 的创建次数。
FieldByIndex([]int) 的实际开销在哪
调用 v.FieldByIndex([]int{0, 0, 1}) 并不是“执行三次索引”，而是按路径逐层解包：先取第 0 字段（结构体），再在其 reflect.Value 上调 Field(0)，再在其上调 Field(1)。每层都会新建一个 reflect.Value 实例，并做一次类型检查和可寻址性校验。
- 每次
Field(i)调用都触发一次 runtime.reflectvaluecall（底层汇编跳转），有固定开销 - 路径越长，
reflect.Value嵌套越深，后续调Interface()或String()等方法时，需要回溯完整路径解析类型 - 若路径中某一层是未导出字段（如小写命名的嵌入字段），
FieldByIndex仍会成功返回值（只要路径合法），但后续读取会 panic —— 这类错误在运行时才暴露，无法靠长度判断
为什么不能缓存中间 reflect.Value
你不能安全地把 v.FieldByIndex([]int{0}) 的结果存起来反复用，因为：
-
reflect.Value是不可变快照，它绑定的是调用时刻的底层地址；如果原结构体被重新赋值（比如s = NewS()），旧reflect.Value仍指向已失效内存 - 即使原值没变，
reflect.Value不支持跨 goroutine 共享（无同步保障），并发读写会导致 data race - 缓存
reflect.Value本身占用堆内存，且 GC 无法及时回收（尤其当它持有大结构体引用时）
实测对比：路径长度 vs 字段扁平化访问
对嵌套三层结构体 A{B: B{C: C{X: 42}}}，以下两种方式在 100 万次循环中耗时差异显著：
立即学习“go语言免费学习笔记（深入）”；
-
v.FieldByIndex([]int{0, 0, 0}).Int()：约 180ms - 提前展开为
v.Field(0).Field(0).Field(0).Int()：约 165ms（省去切片索引解析） - 更优：用指针直接取地址 +
unsafe计算偏移（仅限已知布局的数值字段）：约 8ms
注意：最后一种绕过反射的方式要求结构体字段对齐稳定、无 padding 变动，且仅适用于导出字段或已确认内存布局的场景。
真正容易被忽略的是——StructField.Index 的长度只是路径描述，它不参与运行时计算；但开发者常误以为“只要 Index 长度短就快”，而忽视了每层 Field(i) 调用本身的固定成本和内存分配行为。
