make([]byte, 0, 1024) 更省内存，因预分配容量但不初始化底层数组，避免多次 append 触发扩容和旧数组残留；而 make([]byte, 1024) 立即分配并初始化 1024 字节。
为什么 make([]byte, 0, 1024) 比 make([]byte, 1024) 更省内存
预分配切片容量但不初始化底层数组，能避免后续追加时频繁扩容和旧数组残留。Go 的切片扩容策略是“小于 1024 时翻倍，否则每次增加 25%”，多次 append 可能触发 3–4 次内存分配，且旧底层数组在 GC 前无法释放。
- 用
make([]T, 0, cap)初始化空切片，明确预期容量 - 若已知数据量（如读取 HTTP body），直接传入预估大小，而非默认
make([]byte, n) - 注意：
len == 0但cap > 0的切片仍可安全append，不会触发首次扩容
如何识别并修复 goroutine 泄漏导致的内存持续增长
泄漏的 goroutine 会持有其栈上变量的引用，进而阻止相关堆内存被回收。常见于未关闭的 channel、忘记 cancel() 的 context.Context、或无限等待的 select。
- 用
runtime.NumGoroutine()定期打点，突增即可疑 - 通过
pprof/goroutine?debug=2查看所有 goroutine 的调用栈（需开启net/http/pprof） - 检查所有
go f()调用是否配对了退出机制（如ctx.Done()监听、channel 关闭判断） - 避免在循环中无条件启动 goroutine，尤其配合未缓冲 channel 时极易阻塞并累积
为什么 sync.Pool 不总能降低内存分配，反而可能拖慢性能
sync.Pool 适合复用**生命周期短、创建开销大、且对象大小较稳定**的临时对象（如 *bytes.Buffer、自定义 parser 结构体）。但它有明显代价：Pool 对象只在 GC 前被清理，且 Get/Put 涉及 mutex 和指针操作；若对象太小（如 struct{int}）或复用率低，反而增加调度和内存碎片。
- 优先用于 > 128B、构造成本高（含 malloc 或复杂初始化）的对象
- 避免 Put 已被外部引用的对象，会导致悬垂指针和不可预测行为
- 测试时对比
go tool pprof -alloc_objects和-alloc_space，确认实际减少的是对象数量而非仅延迟分配 - 不要为每个函数都加 Pool——先用
go run -gcflags="-m -m"确认是否真在堆上分配
哪些字段类型会让结构体悄悄变“胖”，拖累内存和缓存局部性
Go 结构体按字段声明顺序布局，并自动填充对齐字节。不当的字段顺序可能导致额外填充，单个结构体浪费几字节，百万实例就是 MB 级别浪费；更严重的是破坏 CPU 缓存行（通常 64 字节）利用率。
立即学习“go语言免费学习笔记（深入）”；
- 把大字段（
int64、struct{...}、指针）放在前面，小字段（bool、int8）放后面 - 避免在结构体中间插入单个
bool——它前后可能各填充 7 字节 - 用
unsafe.Sizeof和unsafe.Offsetof验证布局，或借助github.com/bradfitz/iter类工具分析填充率 - 考虑用
[1]byte替代bool（如果不需要语义清晰性）来彻底消除对齐间隙，但需权衡可读性
sync.Pool 误用比不用还差的情况，在中小规模服务里很常见。优化前务必先用 pprof 定位真实瓶颈，不是所有 “new” 都该被干掉。 
