结构体字段应按对齐值降序排列（8→4→2→1）以减少填充字节；需用unsafe.offsetof或structlayout工具验证填充位置，避免小字段夹在大字段间引发额外padding。
结构体字段顺序怎么排才不浪费内存
Go 不会自动重排字段，声明顺序直接决定内存布局。错的顺序会让编译器在字段之间塞大量 padding，比如 bool 后紧跟 int64，前面就得补 7 字节对齐——看着只写了几行字段，实际内存翻倍。
- 按对齐值从大到小排：
int64/float64/*T（8 字节）→int32/uint32（4 字节）→int16（2 字节）→bool/byte（1 字节） - 相同大小字段连续写，比如多个
int64放一起，避免被小字段割裂 - 别用
_ [n]byte手动填充——那是调试或 ABI 兼容用的，正常优化靠排序就够了
怎么验证结构体有没有被优化
光看代码猜不准，必须用 unsafe.Sizeof 实测。改完前后一比，差值就是省下来的字节。
-
fmt.Println(unsafe.Sizeof(User{}))输出的是实际占用字节数，不是字段和 - 配合
unsafe.Offsetof可查每个字段起始偏移，确认填充是否被压缩 - 64 位系统下，
int64+int32+bool声明顺序不同，结果可能是 16 字节或 24 字节
传结构体时该用值还是指针
不是“越大越要用指针”，而是看拷贝成本和使用意图。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先用指针的情况：
unsafe.Sizeof(T{}) > 16、函数内要改字段、高频调用（如 HTTP handler）、结构体放进[]T或map[K]T - 值传更合适的情况：结构体 ≤ 3 个机器字（64 位下约 24 字节以内）、只读且生命周期短（编译器可能栈分配，逃逸分析友好）
- 别为了“统一风格”全用指针——
func (u User) String()在小结构体上比func (u *User) String()更轻量
高频创建的结构体怎么复用不爆 GC
每秒新建几千个 LogEntry 或 RequestState，GC 很快就报警。复用不是“不 new”，而是让 new 的次数可控、可预测。
- 用
sync.Pool管理实例，但必须配Reset()方法：归还前清空所有可变字段（如切片用s = s[:0]，map 用clear(m)） -
Pool的New函数只负责首次构造，Get后不能假设字段是零值，必须显式重置 - 避免把带资源（文件句柄、未关闭的
net.Conn）或状态残留风险的结构体丢进Pool
字段顺序、拷贝方式、复用机制这三件事得一起看——单点优化容易白忙，比如结构体排好了却还在高频 new 指针，或者用了 sync.Pool 却忘了 Reset，旧数据污染新请求。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
