unsafe.Offsetof仅支持一级字段，嵌套字段需分步计算外层偏移加内层偏移，且字段必须可导出；实际偏移受内存对齐影响，应以Offsetof结果为准，避免手算或硬编码。
unsafe.Offsetof 不能直接用于嵌套结构体的深层字段
unsafe.offsetof 只接受「结构体类型中的一级字段名」作为参数，比如 unsafe.offsetof(s.field) 合法，但 unsafe.offsetof(s.nested.inner) 会编译失败：go 不允许在 offsetof 中使用选择器链。这不是限制而是设计使然——offsetof 的语义是「从结构体起始地址到该字段起始地址的字节偏移」，它只认顶层字段。
常见错误现象：invalid argument s.nested.inner (type int) for unsafe.Offsetof。这是因为 s.nested.inner 已经是值（int），不是字段标识符。
- 必须先拿到外层嵌套字段的偏移，再叠加内层字段在嵌套结构体内的偏移
- 不能对变量实例调用，只能对字段表达式（且不含方法调用、索引、解引用）使用
- 字段名必须可导出（首字母大写），否则无法在包外访问，
Offsetof也会报错
正确计算嵌套字段偏移：分步加法 + 类型断言
核心思路是把嵌套路径拆成两段：外层结构体 → 嵌套字段；嵌套字段类型 → 目标字段。两者偏移相加即为最终结果。
例如有结构体：
type Inner struct { X int }
type Outer struct { A byte; Nested Inner; B int }
想算 Nested.X 相对于 Outer{} 起始地址的偏移：
-
unsafe.Offsetof(Outer{}.Nested)得到Nested字段起始偏移（比如 1） -
unsafe.Offsetof(Inner{}.X)得到X在Inner中的偏移（比如 0） - 两者相加：1 + 0 = 1
注意：不能写 unsafe.Offsetof(Outer{}.Nested.X) —— 这不是合法字段表达式；也不能用 unsafe.Offsetof((*Outer)(nil).Nested.X)，因为 (*Outer)(nil).Nested 是非法内存访问（nil 解引用）且仍不满足字段表达式要求。
实际使用时务必考虑内存对齐和填充
Go 编译器会按字段类型大小和 alignof 规则自动插入填充字节，所以偏移量不是简单累加。比如：
type Packed struct { A byte; B uint64 }
unsafe.Offsetof(Packed{}.B) 通常是 8（不是 1），因为 uint64 要求 8 字节对齐，编译器在 A 后插入了 7 字节 padding。
- 永远以
unsafe.Offsetof实际计算结果为准，不要手算 - 不同架构（amd64 vs arm64）、不同 Go 版本可能因对齐策略微调而改变偏移（虽少见，但存在）
- 若依赖偏移做反射或内存操作（如序列化/zero-copy），建议搭配
unsafe.Sizeof和unsafe.Alignof一起验证布局
替代方案：用 reflect.StructField.Offset 更安全但稍慢
如果只是需要运行时动态获取嵌套字段偏移（比如写通用序列化库），reflect 包更稳妥：
t := reflect.TypeOf(Outer{})
nestedField, _ := t.FieldByName("Nested")
xField, _ := nestedField.Type.FieldByName("X")
offset := nestedField.Offset + xField.Offset
优点是逻辑清晰、支持任意深度嵌套、无需担心字段导出性（只要能拿到 reflect.Type）；缺点是性能开销比 unsafe.Offsetof 大，且无法在常量上下文中使用（比如数组长度声明）。
真正难的不是怎么算，而是记住：偏移是相对于结构体起始地址的静态常量，但它依赖整个字段布局——改一个字段顺序、增一个 byte 字段，后面所有偏移都可能变。别把它当魔法数字硬编码进逻辑里。
