go结构体实际内存占用必须用unsafe.sizeof测量，它返回含padding的对齐后总大小；字段偏移需用unsafe.offsetof验证，因编译器按声明顺序插入填充以满足各字段对齐要求，顺序不当会导致30%～50%空间浪费。
Go结构体的内存占用不是字段大小简单相加，而是受内存对齐规则严格约束；不调整字段顺序，unsafe.Sizeof 返回的大小可能比预期多出 30%～50% 字节。
怎么算清楚一个struct实际占多少字节？
别靠手算，用 unsafe.Sizeof 直接测——但要注意它返回的是「对齐后总大小」，不是字段原始和。
-
unsafe.Sizeof返回值包含填充字节（padding），且是结构体整体对齐值的整数倍 - 用
unsafe.Offsetof查每个字段真实偏移量，能看清哪段被填了 - 例如：
type S struct{ a int8; b int64; c int8 }在 64 位系统上，unsafe.Sizeof(S{})是 24，不是 10
为什么字段顺序一换，大小就变了？
Go 编译器按声明顺序逐个放置字段，并为下一个字段预留满足其对齐要求的起始地址；中间空隙就是 padding。
- 大字段（如
int64、string）对齐值是 8，必须从 0、8、16… 地址开始 - 小字段（如
int8、bool）对齐值是 1，可紧挨着放，但若前面留了空，它们填不满就浪费 - 把所有
int64放最前，再放int32，最后放int8和bool，通常能最小化 padding
哪些类型对齐值容易踩坑？
常见类型对齐值不是都等于自身长度：指针、string、interface{}、complex128 都是 8 字节对齐，哪怕内容只占几个字节。
-
string占 16 字节（2 个uintptr），但对齐值仍是 8 —— 它必须落在 8 字节边界上 -
struct{ x byte; y string }中，y的起始地址必须是 8 的倍数，x后面会强制补 7 字节 - 嵌套 struct 时，内层 struct 的对齐值取其最大字段对齐值，会影响外层布局
真正难的不是记住规则，而是意识到：字段顺序不是语义问题，而是内存布局问题；一次重排可能让百万级对象节省几 MB 堆内存，但改错顺序反而会让 cache line 更难命中。动手前先跑 unsafe.Sizeof 和 unsafe.Offsetof，比凭感觉调更可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
