go struct内存大小以unsafe.sizeof为准，字段偏移由unsafe.offsetof确定，需按对齐值（非类型大小）降序排列字段以减少padding；cgo需同步对齐策略，嵌套struct继承最大对齐值，struct{}不省空间但可减堆分配。
Go struct 的内存大小不是字段字节数加总，unsafe.Sizeof 返回值才是唯一可信结果；字段顺序不对，padding 可能翻倍——16 字节变 24 字节非常常见，这不是风格问题，是硬件访问约束下的硬性空间浪费。
怎么算字段起始偏移？别猜，用 unsafe.Offsetof
每个字段的起始地址不是“上一个字段结束位置+1”，而是向上取整到本字段 unsafe.Alignof 值的倍数。比如 int64 对齐值是 8，前面字段结束在偏移 9，那它就得跳到 16 才能放，中间空出的 6 字节就是 padding。
-
unsafe.Alignof(uint16(0)) == 2表示该类型变量自身地址必须是 2 的倍数，但它在 struct 里具体在哪，取决于前面所有字段的累积大小和对齐规则 - 真正验证字段位置，必须用
unsafe.Offsetof(T{}.field)，而不是靠类型大小推算 - 常见错误：以为
struct{a int8; b int64; c int32}中c偏移是 9 —— 实际是 16，因为b占 8 字节（偏移 0–7），结束于 8，c要求 4 字节对齐，下一个满足的位置是 12？不，b结束于偏移 8，但b类型占 8 字节，所以结束位置是 8，下一地址是 8；而c起始需是 4 的倍数，8 已满足，所以c从 8 开始？错——b是int64，占 8 字节，若它从偏移 0 开始，则占 0–7，结束于偏移 8；那么c起始地址是 8，8 % 4 == 0，确实可放；但若前面是a int8（偏移 0）、b int64（必须从 8 开始），则b占 8–15，结束于 16，c就得从 16 开始
字段怎么排才能最小化 padding？按对齐值，不是按类型大小
对齐值（unsafe.Alignof(T(0))）决定字段“站位门槛”，不是类型本身占多少字节。例如：int64、string、[]byte、指针、interface{} 对齐值都是 8；int32、float32 是 4；bool、int8、[1024]byte 是 1。
- 把对齐值为 8 的字段（如
int64、string、map[string]int）放在最前 - 对齐值为 4 的字段（如
int32）集中放中间 - 对齐值为 1 的字段（如
bool、int8）挤在最后，成组排列（避免bool–int64–bool这种陷阱） - 嵌套
struct按其自身最大对齐值参与排序，不是看它包含什么字段
cgo 场景下 struct 对齐不一致会直接 panic
C 和 Go 默认对齐策略不同，尤其当 C 端用了 #pragma pack(1) 或 __attribute__((packed))，而 Go 端没适配，读写就会越界、随机 panic 或静默数据损坏。
- 不要依赖字段顺序“碰巧一致”——C 头文件改一行，Go 端就可能崩溃
- 验证方法：用
C.sizeof_struct_xxx和unsafe.Sizeof(GoStruct{})对比，不等就一定有问题 - 同步手段包括：在 Go
struct中插入_ uint32填充、调整字段顺序、或在// #include前加对应pragma声明 - 嵌套
struct会继承内部最大对齐值，比如内嵌一个含int64的struct，整个外层struct对齐值就变成 8
空 struct{} 不占内存但影响对齐边界
struct{} 本身大小是 0，unsafe.Sizeof(struct{}{}) == 0，但它在 struct 中仍参与对齐计算——如果它前面字段结束在奇数地址，后面字段仍要按自己对齐值跳转。
- 常见误用：
type Flag struct { _ struct{}; data int64 }→data起始偏移仍是 0，没节省空间；真正省的是作为mapvalue 或channel元素时的堆分配开销 - 它不解决 padding，只解决“零值无分配”问题；想压缩结构体，必须靠字段重排或显式填充
- 最容易被忽略的是嵌套
struct的对齐传染性，以及 cgo 场景下无提示的静默错位——错位后读出来的可能是相邻字段的高位字节，值完全不可控
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
