make([]int, 0, n) 更省内存，因其仅分配底层数组而不初始化元素；make([]int, n) 则初始化 n 个零值并可能引发多次扩容拷贝。
为什么 make([]int, 0, n) 比 make([]int, n) 更省内存？
因为前者只分配底层数组，不初始化元素；后者会把 n 个 0 写进内存，还可能触发后续扩容时的重复拷贝。尤其当你要往里面 append 几百个值，但初始长度只是 0 时，预分配容量能直接避开前几次扩容——Go 的 slice 扩容策略是：小容量时翻倍，大容量时约 1.25 倍，每次扩容都要 malloc 新底层数组 + memmove 旧数据。
- 场景典型：从数据库读一批记录、解析 JSON 数组、批量处理日志行
- 错误现象：
pprof显示大量runtime.makeslice和runtime.growslice调用，GC 压力高 - 注意：
len(s) == 0但cap(s) == n时，s[0]会 panic，必须用append或显式赋值到s[i]（且i ）
append 触发扩容时，底层数组是否复用？
取决于当前容量是否足够。如果 len(s)+1 ，就直接复用；否则新建数组。但这里有个隐蔽坑：即使你预分配了容量，只要中间有其他变量引用原底层数组，Go 就不敢复用——因为要保证“修改新 slice 不影响旧 slice”。所以别让一个底层数组被多个活跃 slice 持有。
- 常见错误：循环中反复
append到同一个 slice，但某次append后把它传给了 goroutine 或存进了 map，导致后续扩容必然新建底层数组 - 验证方法：打印
&s[0]（取首元素地址），扩容前后对比是否变化 - 性能影响：频繁新建底层数组 → 分配压力上升 + 缓存局部性变差
如何估算预分配容量？不能精确时怎么办？
优先用已知上限：比如查数据库带 LIMIT 1000，就 make([]Item, 0, 1000)；HTTP 请求头最多 100 个，就预设 100。无法预估时，宁可略高估（比如乘以 1.5），也不要低估——一次扩容成本远高于多占一点内存。
- 避免用
len(data)当容量：如果data是另一个 slice，它可能刚扩容过，cap(data)才是真实可用空间 - 兼容性注意：Go 1.22+ 对小 slice（
- 极端情况：如果最终长度远小于预分配值（比如预设 10000，实际只存 3 个），可以用
s = s[:len(s)]截断，但一般没必要——空闲容量不参与 GC，也不影响后续append
用 copy 替代多次 append 的边界条件
当你有一批已知长度的数据（比如另一个 slice、数组或固定大小的 buffer），直接 copy 比循环 append 快得多——少了 len/cap 检查、少了多次边界判断、底层是 memmove 汇编优化。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：
dst := make([]byte, len(src)); copy(dst, src)，不是append(dst, src...) - 错误现象：
append(dst, src...)在 src 很长时明显慢，pprof 里能看到runtime.slicecopy被调用多次 - 注意：
copy不检查目标容量，务必确保len(dst) >= len(src)，否则静默截断
make([]T, 0, N) 反而增加心智负担。真正关键的是：**看 pprof，找 growslice 热点，再决定在哪预分配、预多少**。 
