应预分配容量，即用make([]T, 0, n)而非make([]T, n)或无容量声明；因高频循环中append若未预估长度，会频繁触发runtime.growslice，导致内存分配与数据拷贝开销剧增。
能预估最终长度，就别让 append 自己猜——热路径上每次扩容都意味着内存分配 + 数据拷贝，直接拖慢吞吐。
怎么判断该不该预分配
看这个切片是不是在高频循环里反复 append，且最终长度可估算。比如读取 HTTP 响应 JSON 数组、解析日志行、批量处理数据库查询结果。如果长度完全随机（如用户输入拼接），预分配意义不大；但如果已知大概 10 万条记录，或文件有 stat.Size() 可推断行数，就必须预分配。
- 错误信号：
pprof显示runtime.makeslice或runtime.growslice占 CPU 热点前 3 - 更隐蔽的坑：用
make([]T, n)初始化，会把前n个元素填零值，而你其实只想攒数据——该用make([]T, 0, n) - 注意：小切片（
cap ）扩容翻倍，大切片按 1.25 倍增长，但哪怕只触发 3 次扩容，也意味着至少 3 次底层数组拷贝
make([]T, 0, n) 和 make([]T, n) 的实际差别
两者都分配了底层数组，但语义和后续行为完全不同：
-
make([]int, 0, 1000)：len=0，cap=1000，append前 1000 次都不扩容，内存一次到位 -
make([]int, 1000)：len=1000，cap=1000，所有位置已初始化为0，如果你本意是“先空着再填”，这就浪费了初始化开销，还可能误导逻辑（比如误以为s[0]是有效数据） - 反模式：
s := []int{}+ 循环append(s, x)—— 对于 10 万元素，平均触发约 17 次扩容，实测比预分配慢 90% 以上
批量追加比单个 append 更省
热路径里别写 for _, x := range data { s = append(s, x) }。Go 的 append 是内置函数，每次调用都有边界检查和 len/cap 判断开销。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确姿势：
s = append(s, data...)，把整个源切片展开传入，一次完成复制，避免 N 次函数调用和重复检查 - 前提：确保
data本身不逃逸（比如它来自栈上数组或池化对象），否则反而增加 GC 压力 - 如果
data是大[]byte，注意它可能钉住整个底层数组——必要时先copy到新切片释放旧引用
复用切片比每次都 make 更适合超高频场景
每秒处理数万次请求时，即使预分配也会频繁创建/丢弃切片对象，GC 压力明显。这时应复用：
- 简单复用：
s = s[:0]清空长度但保留底层数组，下次继续append（前提是容量足够且生命周期可控） - 跨 goroutine 安全复用：用
sync.Pool缓存预分配好的切片，例如var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 4096) }} - 风险点：从
sync.Pool获取的对象内容未清零，必须手动s = s[:0]或显式覆盖，否则可能泄露旧数据
真正难的不是知道要预分配，而是判断“容量该设多大”——设小了还是扩容，设大了浪费内存甚至导致 GC 延迟上升。生产环境建议结合 go tool pprof 实际采样，而不是凭感觉拍个 2 倍。
