Go语言没有padding函数，struct内存填充由编译器静态决定；唯一可靠工具是unsafe包的Offsetof和Sizeof，用于实测字段偏移与结构体大小。
Go 语言没有“填充函数”这种东西——padding 是编译器在 struct 布局时自动插入的字节，不是运行时调用的函数，也不能手动“调用”或“处理”。所有所谓“Padding 函数”的说法，都是对内存对齐机制的误解。
为什么找不到 padding 相关函数或包
Go 标准库中不存在 padding、padStruct、alignStruct 这类函数。struct 的内存填充（padding）完全由编译器在编译期静态决定，不依赖任何运行时逻辑。你无法 import 一个“padding 包”，也无法在代码里写 pad(s) 来调整布局。
- 常见误操作：搜索 “go padding function” 后试图引入第三方库，结果发现只是封装了
unsafe.Sizeof或字节拷贝逻辑，和真正内存对齐无关 - 真实依赖项只有
unsafe包里的Sizeof、Offsetof、Alignof—— 它们是观察工具，不是控制手段 - 所谓“处理 padding”，本质是重排 struct 字段顺序 + 实测验证，不是调用某个函数
unsafe.Offsetof 和 unsafe.Sizeof 是唯一可信的检测手段
别靠类型大小加总猜偏移，CPU 不认手算。必须用这两个函数实测，否则优化就是拍脑袋。
-
unsafe.Offsetof(s.field)返回字段真实起始偏移（单位：字节），例如unsafe.Offsetof(s.b)可能返回8而非1 -
unsafe.Sizeof(s)返回整个 struct 占用字节数（含所有 padding），例如struct{a int8; b int64}返回16，不是9 - 必须在定义该 struct 的包内调用，不能在其他包用反射或表达式传参，否则 panic（Go 1.21+）
- 示例：
type T struct{ a int8; b int64; c int32 }<br>s := T{}<br>fmt.Println(unsafe.Offsetof(s.a), unsafe.Offsetof(s.b), unsafe.Offsetof(s.c)) // 0 8 16<br>fmt.Println(unsafe.Sizeof(s)) // 24
字段顺序怎么排才真省空间
核心原则：按字段的 unsafe.Alignof 值降序排列，不是按类型大小，也不是按字母顺序。
立即学习“go语言免费学习笔记（深入）”；
- 对齐值为 8 的字段（
int64、string、[]byte、map、interface{}、指针）放最前 - 对齐值为 4 的字段（
int32、float32、rune）放中间 - 对齐值为 1 的字段（
bool、int8、byte、[N]byte）挤在最后，且尽量连续（避免bool–int64–bool这种断层） - 嵌套 struct 按其自身
unsafe.Alignof参与排序，不是看它里面有什么；它的尾部 padding 会“传染”到外层
最容易被忽略的一点：单个 struct 大小相同，并不代表内存效率一致。数组 []T 中每个元素都独立对齐，字段顺序差一点，每个元素就多几字节“开头税”，百万级实例下就是 MB 级浪费——而这个差异，unsafe.Sizeof 看不出来，必须结合 unsafe.Offsetof 看字段分布。
