go结构体字段顺序直接影响内存占用，错误排序因填充字节增多可致内存浪费50%；编译器按声明顺序分配并插入padding以满足对齐要求，如bad{a bool,b int64,c int32}占24字节，good{b int64,c int32,a bool}仅16字节。
Go结构体字段顺序直接决定内存占用大小，不优化可能多浪费50%内存；这不是理论问题，而是线上服务GC压力、缓存命中率下降的常见根源。
struct字段顺序怎么影响unsafe.Sizeof结果
Go编译器不会重排字段，而是严格按声明顺序分配，并在必要位置插入padding字节，确保每个字段起始地址满足其对齐要求（如int64必须从8的倍数地址开始）。顺序一错，padding就会暴涨。
-
type Bad { a bool; b int64; c int32 }：实际占24字节（a后被迫填7字节，c后补3字节） -
type Good { b int64; c int32; a bool }：仅占16字节（b占0–7，c占8–11，a占12，末尾补4字节对齐到16） - 差异在单个结构体上看似不大，但放大到
[]Good百万级切片时，就是MB级内存差
哪些字段对齐值是关键？unsafe.Alignof不能乱猜
unsafe.Alignof返回的是类型自身的对齐约束，不是它在struct里的偏移——真正决定填充位置的是unsafe.Offsetof。字段对齐值通常等于其大小，但最大不超过8（64位系统）：
- 8字节对齐：
int64、float64、uintptr、所有指针、string、interface{} - 4字节对齐：
int32、float32、rune - 2字节对齐：
int16、uint16 - 1字节对齐：
bool、byte、int8
别用Alignof推测字段地址，Offsetof才是实测依据。
为什么interface{}和指针要特别小心
interface{}固定占两个机器字（16字节），含类型头+数据指针/值拷贝；而*T只占一个机器字（8字节）。高频日志或参数传递中，fmt.Printf("%v", x)会隐式转成interface{}，小对象可能逃逸并触发额外分配。
- 传参时优先用
*T而非interface{}，除非真需要运行时类型擦除 - 含
interface{}的struct，其整体对齐值至少为8，且字段间padding更难预测 - CGO场景下，C struct和Go struct对齐不一致会直接崩溃，必须用
#pragma pack或//go:align显式控制
验证结构体布局必须用unsafe.Offsetof和unsafe.Sizeof
光看字段类型组合猜padding，90%会错。尤其含嵌套struct、slice、指针或interface{}时，真实布局和直觉差距极大。
- 用
unsafe.Sizeof(T{})确认总大小 - 用
unsafe.Offsetof(t.field)查每个字段真实偏移（注意：只能传字段名，不能传表达式） - 写个简单
main函数跑一遍，比查文档快十倍 - 别依赖IDE提示或静态分析工具——它们不模拟真实内存布局
最常被忽略的一点：结构体总大小必须是其最大字段对齐值的整数倍，所以末尾补空是常态；而数组中每个元素都独立对齐，字段顺序的微小差异会在切片里被指数级放大。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
