go struct字段顺序影响内存占用：按类型大小对齐填充，大字段优先排列可减少padding；interface{}比*t多8字节因含类型信息头；cgo需统一struct对齐避免崩溃。
struct 字段顺序怎么影响内存占用
Go 的 struct 内存布局不是按声明顺序简单拼接，而是按字段类型大小做对齐填充。字段排得越“松散”，浪费的 padding 就越多。
比如 struct{ a uint8; b uint64; c uint8 } 实际占 24 字节（a 占 1 字节，后面填 7 字节对齐到 8 字节边界；b 占 8 字节；c 占 1 字节，再填 7 字节对齐到结构体末尾）；而改成 struct{ b uint64; a uint8; c uint8 } 就只要 16 字节（b 占 8，a 和 c 紧挨着占 2，末尾补 6 字节对齐到 16）。
- 字段从大到小排列，通常能最小化 padding
- 同类型字段尽量连续（比如多个
uint32放一起），避免被小类型隔开 - 用
unsafe.Sizeof和unsafe.Offsetof验证实际布局，别靠猜
为什么 interface{} 比 *T 多占 8 字节
因为 interface{} 是两字宽结构：一个字宽存类型信息指针，一个字宽存数据指针或值拷贝。当装入小值（如 int32）时，它会把值直接塞进第二个字宽里；但装入大值（比如超过 8 字节的 struct），就会分配堆内存并存指针——这时候和 *T 表面看一样，但多了类型头开销。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传参时用
*T而非interface{}，除非真需要运行时类型擦除 -
fmt.Printf("%v", x)会隐式转成interface{}，高频日志里注意小对象逃逸和额外分配 - 用
go tool compile -gcflags="-m"看是否发生不必要的接口转换
unsafe.Alignof 返回的值到底是谁的对齐要求
unsafe.Alignof 返回的是该类型**自身**的对齐约束，不是它在 struct 中的偏移。比如 unsafe.Alignof(uint16(0)) == 2，意思是任何 uint16 变量地址必须是 2 的倍数；但它在 struct 里具体放哪，还取决于前面字段总大小和对齐规则。
- 结构体整体对齐值 = 所有字段
unsafe.Alignof的最大值 - 字段起始偏移 = 上一字段结束位置向上对齐到本字段
Alignof - 不要用
Alignof推测字段地址，用Offsetof更直接
CGO 场景下 struct 对齐不一致导致崩溃
C 代码里 struct 默认按编译器规则对齐（GCC/Clang 常用 __attribute__((packed)) 控制），而 Go 编译器按自己的规则来。如果 C 头文件没显式对齐声明，直接用 //export 或 import "C" 绑定，字段错位会导致读写越界、随机 panic 或静默数据损坏。
- 在 C 头中为跨语言 struct 加
#pragma pack(1)或__attribute__((packed))，并在 Go 侧用// #include <...></...>后加对应 pragma - 用
unsafe.Sizeof和 C 的sizeof对比验证，不等就一定有问题 - 宁可手动展开字段映射，也不要依赖自动生成的 C.struct_xxx —— 它不保证与 C 端内存布局一致
对齐不是玄学，但容易被当成透明层忽略；一旦涉及 CGO、序列化、unsafe 指针运算，它立刻变成最硬的那块石头。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
