Go struct字段顺序影响内存占用，因对齐规则需插入padding；小字段穿插大字段会增加填充，重排为降序可减少浪费；interface{}比*T多8字节；CGO需统一#pragma pack对齐；务必用unsafe.Sizeof和Offsetof实测验证。
struct字段顺序直接影响内存占用大小
Go struct不是按声明顺序线性拼接，而是每个字段按自身unsafe.Alignof要求对齐，中间插入padding。字段排得越“散”，浪费越多。
常见错误现象：把小字段（如int8、bool）穿插在大字段（如int64、string）之间，导致大量填充字节。
-
struct{a int8; b int64; c int16}占24字节（a后填7字节对齐b，c后填6字节对齐结构体末尾） -
struct{b int64; c int16; a int8}只占16字节（b占0–7，c占8–9，a占10，末尾补6字节到16） - 数组
[]T会放大单个元素的padding——10万条记录时，多1字节padding就是100KB额外内存 - 别靠经验猜布局，必须用
unsafe.Sizeof(T{})和unsafe.Offsetof(t.field)实测
interface{}比*T多8字节不是偶然
interface{}是两字宽结构：一个字宽存类型信息，一个字宽存数据指针或值拷贝。哪怕装的是int32，也固定占16字节（64位平台）；而*T只占8字节。
使用场景中容易踩坑：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
fmt.Printf("%v", x)隐式转interface{}，高频日志里小对象会逃逸+额外分配 - 函数参数用
interface{}接收任意类型，但若实际只传*T，就白多8字节开销 - 缓存结构中存
interface{}而非具体指针，会显著增加GC压力和内存 footprint
CGO跨语言struct对齐不一致会崩溃
Go默认按自身规则对齐，C编译器（GCC/Clang）默认按平台规则对齐，两者不一致时字段错位，读写越界、随机panic或静默数据损坏。
实操建议：
- C头文件中为共享struct加
#pragma pack(1)或__attribute__((packed)) - Go侧
// #include "xxx.h"前加对应#pragma pack(1)（注意顺序） - 用
unsafe.Sizeof和C的sizeof对比验证，不等就一定有问题 - 避免在CGO中直接传递未显式对齐声明的struct，宁可拆成字段逐个传
对齐边界不是字段大小，而是类型自身的约束
unsafe.Alignof(uint16(0)) == 2表示该类型变量地址必须是2的倍数，但它在struct里的偏移还取决于前面字段总大小和对齐规则。结构体整体对齐值 = 所有字段unsafe.Alignof的最大值。
容易混淆的点：
-
unsafe.Alignof返回的是类型自身的对齐要求，不是它在struct中的偏移量 -
unsafe.Offsetof才是查字段真实起始位置的唯一可靠方式 - 嵌套struct时，外层对齐由内层最大字段决定，不是简单相加
- 含
slice、map、interface{}的struct，其size和offset受运行时影响，unsafe只能测空值布局
