go struct内存大小以unsafe.sizeof为准，字段偏移由unsafe.offsetof确定，必须按对齐值（非类型大小）降序排列字段以减少padding；cgo需同步对齐策略，嵌套struct继承最大对齐值，struct{}不省空间但可减堆分配。
Go struct 的内存大小不是字段字节数加总，unsafe.Sizeof 返回值才是唯一可信结果；字段顺序不对，padding 可能翻倍——16 字节变 24 字节非常常见，这不是风格问题，是硬件访问约束下的硬性空间浪费。
字段偏移由 unsafe.Alignof 决定，不是类型大小
每个字段起始地址必须是自身 unsafe.Alignof 值的整数倍。比如 int64 的对齐值是 8，它前面字段结束于偏移 9，那它就得跳到 16 才能放，中间空出的字节就是 padding。
-
unsafe.Alignof(int64(0)) == 8，但int8、bool、[1024]byte的对齐值都是 1 -
string、[]byte、指针、interface{}对齐值也是 8 -
int32、float32、rune对齐值是 4 - 字段实际偏移 = 上一字段结束位置向上取整到本字段对齐值的倍数
按对齐值降序排列字段，而非按类型大小
把对齐值大的字段往前放，小的往后挤，才能压缩 padding 总量。编译器不会自动重排字段顺序，全靠你手动控制。
- 8 字节对齐组：
int64、string、map[string]int、指针、interface{} - 4 字节对齐组：
int32、float32 - 1 字节对齐组：
bool、int8、byte—— 这些要成组连续声明，避免穿插在大字段之间 - 嵌套
struct按其自身最大对齐值参与排序，不是看它包含什么字段
验证必须用 unsafe.Offsetof 和 unsafe.Sizeof 配合
光看 unsafe.Sizeof 只知道总大小是否异常；光看 unsafe.Offsetof 不知道字段之间是否留空；两者结合才能定位浪费点。
-
unsafe.Offsetof(s.b) - unsafe.Offsetof(s.a) > unsafe.Sizeof(s.a)就说明 a 和 b 之间有 padding - 推荐工具：
go install github.com/dominikh/go-tools/cmd/structlayout@latest，然后运行structlayout yourpkg YourStruct - 输出中带
gap [7]byte的行，就是插了 7 字节 padding 的位置 - 不要依赖
reflect.StructField.Offset在运行时校验 —— 它和unsafe.Offsetof等价，但必须在定义该 struct 的包内调用
cgo 场景下对齐不一致会直接 panic
C 和 Go 默认对齐策略不同，尤其当 C 端用了 #pragma pack(1) 或 __attribute__((packed))，而 Go 端没适配，读写就会越界、随机 panic 或静默数据损坏。
- 不要依赖字段顺序“碰巧一致”——C 头文件改一行，Go 端就可能崩溃
- 显式同步方式：用
_ uint32手动补齐、调整字段顺序、或在 cgo 注释中引入// #include <stdalign.h></stdalign.h> - 嵌套 struct 的尾部 padding 会传染到外层：内层
unsafe.Sizeof(Inner{})含 padding，外层字段大小就按这个算，不是按字段原始长度之和 -
struct{}本身大小是 0，但它仍参与对齐计算——如果它前面字段结束在奇数地址，后面字段仍要按自己对齐值跳转
真正容易被忽略的是嵌套 struct 的 padding 传染性，以及 cgo 中对齐策略必须显式对齐，而不是靠“看起来一样”。字段顺序优化只是起点，一旦涉及序列化、cgo 或高频分配，这些边界情况就会立刻暴露出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
