结构体字段偏移量由编译器在编译期静态确定，是字段相对于结构体数据区起始地址的固定字节距离，反射仅暴露该布局信息而非动态计算；其值受字段顺序、类型对齐要求、填充字节及packed等属性影响，与运行时对象头、gc移动无关。
反射本身不改变对象在堆内存中的物理分布，它只是提供一种运行时读取结构布局的视角。字段的内存偏移（Offset）由编译器在类型定义阶段就确定，反映的是该字段相对于结构体起始地址的字节距离，属于静态布局信息，不是反射“计算”出来的，而是反射“暴露”出来的。
偏移量本质是编译期固定的布局结果
Go、C#、Java 等语言中，结构体/类的字段顺序、对齐规则、填充字节（padding）均由编译器依据 ABI 和运行时约束决定。例如：
- 64 位系统上，int64 字段通常按 8 字节对齐，若前面是 int32，中间可能插入 4 字节 padding
- struct{ bool; int64 } 的第二个字段 Offset 很可能是 8，而非 1——因为对齐要求跳过了中间空隙
- 字段是否导出、是否含 interface{} 或 slice，并不影响其 Offset 值，只影响该字段能否被反射“看到”或“安全访问”
反射获取的 Offset 与实际内存位置一致，但不可直接用于指针运算
reflect.StructField.Offset 和 unsafe.Offsetof(T{}.Field) 在标准结构体上必须相等；若不等，说明结构体布局异常（如 cgo 导出、//go:packed、或含非标准字段）。但即使相等，也不能随意用该 Offset 做如下操作：
- 对 string/slice 字段做 *(unsafe.Pointer)(uintptr(unsafe.Pointer(&s)) + f.Offset) 解引用——其底层结构（如 string 是 2 个 uintptr）是运行时实现细节，不承诺稳定
- 跨平台或跨 Go 版本假设 Offset 不变——不同架构（32/64 位）、不同 GC 模式（如 -gcflags="-d=ssa/checkptr"）可能影响布局
- 对接口变量调用 reflect.ValueOf(i).Elem() 后再取字段 Offset——此时拿到的是接口头的字段，不是原始结构体的
堆上对象的物理地址 ≠ 结构体起始地址的简单叠加
一个结构体实例分配在堆上时，其地址是 GC 分配器返回的块首地址，而该地址前通常有对象头（如 go 的 heapBits、Java 的 mark word + klass pointer）。字段偏移是从这个首地址开始算的，但：
- 对象头大小因语言和运行时而异（Go 约 16–32 字节，.NET Core 约 8–12 字节，JVM 可能 8/12/16 字节）
- GC 可能在运行时移动对象（如 .NET 的 compacting GC、Go 的栈增长触发的逃逸对象重分配），导致物理地址变化，但字段相对偏移不变
- 反射看到的 Offset 是相对于结构体数据区起点的，不包含对象头——这也是为什么不能拿它去减对象头长度来“还原原始地址”
真正影响字段物理分布的关键因素
不是反射，而是以下设计选择：
- 字段声明顺序：多数语言按源码顺序布局（除个别优化场景），调整顺序可减少 padding
- 类型大小与对齐要求：把大字段放前面，小字段放后面，更容易紧凑排列
- 是否启用 packed 属性：如 C 的 __attribute__((packed))、Go 的 //go:packed 注释、C# 的 [StructLayout(LayoutKind.Sequential, Pack = 1)]
- 运行时配置：如 JVM 的 -XX:+UseCompactObjectHeaders、GraalVM 的元数据压缩，会影响对象头，间接改变字段起始位置
