结构体字段应按大小降序排列以减少填充，优先指针化大或可选字段，一维切片比二维更缓存友好，sync.pool需重置对象且适用于中大型临时对象。
结构体字段顺序怎么排才能减小 size
Go 编译器按声明顺序布局字段，并自动插入填充字节以满足对齐要求。字段从小到大排列（如 bool、int32、int64）会强制在小字段后补大量 padding，导致结构体膨胀。正确做法是按字段大小降序排列：先 int64、float64、[16]byte 等 8 字节类型，再 int32、float32（4 字节），最后 int16、bool、byte（1–2 字节）。
-
unsafe.Sizeof是验证手段：对比Bad{}和Good{}的实际字节数，差值就是填充浪费 - 字段对齐边界通常是其自身大小，最大不超过 8；
int64必须从地址 %8 == 0 处开始 - 末尾填充不可避免，但中间填充可大幅削减——优化后常见结构体能节省 20%~40% 内存
什么时候该把字段改成指针
不是所有字段都适合指针化。核心判断依据是：该字段是否「大且不常访问」或「可为空」。例如 Metadata 这类含 []string 或 map 的嵌套结构，直接内联会让每个实例都携带冗余数据；而 *Metadata 只占 8 字节，且能延迟加载、分离冷热数据。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 优先指针化大字段（>16 字节）或可选字段（如 API 响应中的
Address） - 避免把小字段（如
bool、int8）全指针化：nil 检查增加分支，多个指针还拉散内存局部性 - 指针本身不逃逸，但所指向对象若动态分配，仍可能堆上分散——需结合
go tool compile -gcflags="-m"确认
一维切片模拟二维布局为什么更缓存友好
用 [][]float64 存矩阵时，每行是独立分配的切片，地址不连续；CPU 预取器无法有效加载下一行数据，缓存行利用率低。改用一维 []float64 + 行优先索引 data[i*cols + j] 后，遍历 i（外层）、j（内层）就变成纯线性访问，64 字节缓存行能装下连续多个元素，命中率显著提升。
- 实测中，相同计算逻辑下，一维布局比二维切片快 1.5–3 倍，尤其在 L1/L2 缓存敏感场景（如数值计算、图像处理）
- 注意：列优先遍历（
j外层、i内层）会退化为跳读，必须严格按行优先顺序写循环 - 初始化时预分配足够容量：
make([]float64, rows*cols)，避免后续扩容导致内存不连续
sync.Pool 复用结构体要注意什么
对固定尺寸结构体（如网络包头、HTTP 中间件上下文），sync.Pool 能避免高频堆分配，减少 GC 压力和内存碎片。但 Pool 不是万能的——它不保证对象复用，也不做类型安全检查，且 GC 会清空内容。
- 每次
Get()返回的对象必须重置字段，不能依赖旧值；推荐用私有构造函数封装初始化逻辑 - Pool 实例应定义为包级变量，而非局部或闭包内，否则无法跨 goroutine 复用
- 小对象（≤ 2 个 machine word）通常栈分配更高效，没必要进 Pool；Pool 更适合 64 字节以上的中大型临时对象
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
