预分配容量避免多次底层数组复制：append 超出 cap 时需申请新数组（1.25–2 倍）并拷贝旧数据，循环中开销显著；make([]T, 0, n) 一次性分配足够空间，更高效。
为什么 make([]T, 0, n) 比 append 累加更高效
因为预分配容量能避免多次底层数组复制。每次 append 超出当前 cap，运行时会申请新数组（通常是旧容量的 1.25–2 倍），再把旧数据拷贝过去——这在循环中反复发生时开销明显。
- 小切片（
len ）：扩容策略是翻倍；大切片则按 1.25 倍增长，但仍可能触发 3–5 次复制 - 若已知最终长度（如读取文件行数、HTTP 响应条目数），直接用
make([]T, 0, expectedLen)一次性配齐cap - 注意：
make([]T, n)会初始化前n个元素（填零值），而make([]T, 0, n)只预留空间，len=0，更符合“先攒数据再用”的场景
append 时传入切片而非单个元素能减少函数调用开销
Go 的 append 是内置函数，但语法糖背后仍有参数检查和边界判断。当批量追加时，把源数据组织成切片再整体 append，比逐个调用快且内存更友好。
- 错误写法：
for _, v := range src { dst = append(dst, v) } - 推荐写法：
dst = append(dst, src...)
（前提是src类型匹配，且你信任其长度） - 若
src是动态生成的（如从 map 遍历得来），先收集到临时切片再展开，比边遍历边append更少触发扩容
用 copy 替代多次 append 实现“零分配”拼接
当目标切片容量已足够（比如提前 make 过），直接用 copy 写入，完全绕过 append 的长度/容量管理逻辑，也没有新增堆分配。
- 适用场景：已知总长度、分段处理、结果写入固定缓冲区（如序列化、IO 写入）
- 示例：
buf := make([]byte, 0, totalSize) offset := 0 for _, part := range parts { n := copy(buf[offset:], part) offset += n } - 关键点：
copy不改变len，所以需手动维护offset；最终可用buf[:offset]得到有效数据
警惕 nil slice 和空 slice 在扩容行为上的差异
nil slice（值为 nil）和 len==0 && cap==0 的空切片，在首次 append 时都触发分配，但初始容量策略不同——这是容易被忽略的性能抖动点。
立即学习“go语言免费学习笔记（深入）”；
-
var s []int（nil）：首次append分配容量为 1（不是 0） -
s := make([]int, 0)（空切片）：首次append也分配容量为 1 - 但
s := make([]int, 0, 100)就明确设了容量，后续 100 次append都不扩容 - 反模式：
var s []int; for i := 0; i → 至少 7 次底层数组复制（1→2→4→8→16→32→64→100）
... 展开、以及用 copy 控制写入位置，这三招覆盖了绝大多数优化场景。 
