结构体字段应按对齐值从大到小排列以减少内存填充，即int64/float64/*T（8字节）→int32/uint32（4字节）→int16（2字节）→bool/byte（1字节），相同大小字段连续声明，并用unsafe.Sizeof验证优化效果。
结构体字段顺序怎么排才不浪费内存
Go 不会自动重排字段，声明顺序直接决定内存布局。错的顺序会让编译器在字段之间塞大量 padding，比如 bool 后紧跟 int64，前面就得补 7 字节对齐——看着只写了几行字段，实际内存翻倍。
- 按对齐值从大到小排：
int64/float64/*T（8 字节）→int32/uint32（4 字节）→int16（2 字节）→bool/byte（1 字节） - 相同大小的字段尽量连续写，比如多个
int64放一起，避免被小字段割裂 - 用
unsafe.Sizeof验证效果：fmt.Println(unsafe.Sizeof(User{}))，改完前后对比，差值就是省下来的字节
传结构体时该用值还是指针
不是“越大越要用指针”，而是看拷贝成本和使用意图。一个 User 有 5 个字段但全是 int 和 string，值传可能比指针解引用还快；但只要含 [1024]byte 或 map[string]string，值传就是在复制整块内存。
- 优先用指针的情况：
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
- 预分配切片字段：结构体里有
data []byte？初始化时make([]byte, 0, 1024)，后续反复用data = data[:0]，底层数组复用
嵌套结构体和 JSON 性能怎么平衡
嵌套让代码好读，但会让 json.Unmarshal 多走几层反射、深拷贝时多分配几块内存。特别是 type A struct { B struct{ C map[string][]byte } } 这种，反序列化一次可能触发十几次堆分配。
立即学习“go语言免费学习笔记（深入）”；
- 扁平优先：用
UserID替代嵌套的User结构体，需要时再查；用CategoryID int而不是Category Category - JSON 场景下，字段尽量用值类型：
CreatedAt time.Time比*time.Time少一次指针解引用和 nil 判断 - 固定结构体务必用
easyjson生成方法，jsoniter.ConfigFastest也能提效，但无法绕过反射开销 - 如果必须嵌套，子结构体本身也得按前述规则优化（字段排序 + 指针传递 + 复用）
最容易被忽略的是：结构体优化从来不是单点动作。改了字段顺序，可能让指针传递收益变小；用了 sync.Pool，但没写 Reset，反而引入数据污染。性能提升藏在组合里，而不是某个“银弹”。
