struct{int8;int64}比struct{int64;int8}多占7字节填充，因前者需在int8后补7字节使int64对齐到8字节边界，后者int64天然对齐，仅末尾补7字节满足整体对齐。
为什么 struct{int8;int64} 比 struct{int64;int8} 多占 7 字节
结构体内存对齐不是编译器“多此一举”，而是 CPU 访问硬件的硬性要求：多数架构（如 x86-64）要求 int64 必须从地址能被 8 整除的位置开始。如果它被挤在偏移量 1 的位置，CPU 可能触发总线错误或降速访问。
Go 编译器会自动插入填充字节（padding），让每个字段按自身对齐要求就位。所以：
-
struct{a int8; b int64}：a 占 1 字节（偏移 0），但 b 要求对齐到 8，编译器在 a 后塞 7 字节 padding，b 从偏移 8 开始 → 总大小 16 -
struct{b int64; a int8}：b 从 0 开始（天然对齐），a 紧跟其后占 1 字节（偏移 8），末尾再补 7 字节使整个 struct 大小是 8 的倍数 → 总大小也是 16，但 a 不用前置 padding
如何用 unsafe.Offsetof 和 unsafe.Sizeof 验证实际布局
光看定义猜不对齐结果？必须实测。Go 提供底层工具直接读取编译器算出的布局，比文档更可信。
常见误判点：以为字段顺序不影响大小，其实影响填充位置；或者忽略 struct 自身也要满足最大字段对齐要求（即末尾 padding）。
立即学习“go语言免费学习笔记（深入）”；
- 用
unsafe.Offsetof(s.b)查b字段起始偏移（s是实例） - 用
unsafe.Sizeof(s)查整个 struct 占用字节数 - 别对未导出字段或空 struct 直接取 offset —— Go 1.21+ 会 panic
- 示例：
type T struct{ a int8; b int64; c int32 } s := T{} fmt.Println(unsafe.Offsetof(s.a), unsafe.Offsetof(s.b), unsafe.Offsetof(s.c)) // 0 8 16 fmt.Println(unsafe.Sizeof(s)) // 24
字段重排真的能省内存吗？什么场景下值得做
能省，但只在高频创建、数量级达万级以上的 struct 实例中才有可观收益。日常 DTO 或配置结构体几乎无感。
- 优先把大字段（
int64、float64、指针、接口）放前面，小字段（bool、int8、byte）集中放后面 - 避免把多个
int8拆开：比如struct{a int8; b int64; c int8}会因 b 插入两段 padding；改成struct{b int64; a,c int8}就只在末尾补 6 字节 - 注意嵌套 struct：内层对齐规则独立生效，外层只看到它的总大小和对齐值（即内层最大字段对齐数）
- 用
go tool compile -gcflags="-S"看汇编时，字段偏移会暴露在注释里，适合深度验证
什么时候不该手动优化 —— 对齐反而破坏可读性或语义
字段顺序常承载业务逻辑含义（比如时间戳永远在前、状态码紧随其后），强行重排会让协作者困惑，也增加序列化/反序列化风险。
- JSON/XML 标签（
json:"field"）不依赖字段物理顺序，但 protobuf 的 tag 编号若靠顺序生成，重排可能隐式改变 wire format - 使用
reflect遍历字段时，Type.Field(i)返回顺序仍按源码顺序，和内存布局无关 —— 别指望靠重排控制反射行为 - CGO 场景下必须严格匹配 C struct 布局？那就不能动字段顺序，得用
//go:pack或#pragma pack配合，而非靠重排 - 现代 CPU cache line（通常 64 字节）比单个 struct 对齐影响更大：一个 struct 若跨 cache line，性能损失远超几字节 padding
真正要盯的，是 struct 是否频繁分配、是否成批进出 channel、是否作为 map key —— 这些地方 padding 才会从“看不见的字节”变成“可测量的延迟”。其他时候，先写清楚，再量，最后调。
