Go切片扩容分阶段、有边界、受对齐影响，并非简单翻倍；nil切片首次append分配容量1，预设cap可避免多次堆分配与数据拷贝，显著提升高频写入性能。
Go切片的扩容不是“翻倍就行”，而是分阶段、有边界、受对齐影响的内存重分配过程；不预估容量就append，高频写入场景下极易触发连续堆分配和数据拷贝，成为隐性性能瓶颈。
为什么append会突然变慢？看扩容触发条件
扩容只在len == cap且调用append时发生，不是每次append都扩容。但一旦触发，就必须分配新底层数组、复制旧数据、更新指针——这三步全在堆上完成。
- nil切片（如
var s []int）第一次append会先分配容量为1的数组 -
make([]int, 0, 0)也是nil切片，行为同上 -
make([]int, 0, 10)是非nil切片，len=0但cap=10，前10次append完全不扩容
扩容策略分三档：小于1024、≥1024、零容量
Go运行时（截至2026年）的growslice函数按当前cap值选择增长因子，不是固定倍率：
- 原
cap == 0→ 新cap = 1 - 原
cap → 新<code>cap = cap * 2（如从512→1024） - 原
cap >= 1024→ 新cap = cap + cap/4（即1.25倍，向上取整到内存对齐边界）
注意：这个1.25倍是cap + cap/4的整数除法结果，不是浮点运算；最终容量还会被round up到元素大小的倍数（如[]int64按8字节对齐）。
立即学习“go语言免费学习笔记（深入）”；
底层数组共享导致的“假扩容”陷阱
切片截取（如s[2:5]）不分配新数组，只是修改array指针和len/cap。但如果后续对这个子切片append，且其cap不足以容纳新元素，就会触发扩容——此时复制的是整个底层数组，而非仅子切片可见部分。
- 示例：
arr := make([]int, 1000); s := arr[990:995]，s的cap是10，append(s, 1)会复制全部1000个元素 - 解决方法：用
make新建切片再copy，或显式限制子切片容量：s := arr[990:995:995]
预分配能省多少？实测差异明显
对已知规模的数据，用make预设cap可彻底避开扩容路径。比如处理10万条日志：
- 未预分配：
s := []string{}; for _, v := range logs { s = append(s, v) }→ 触发约17次扩容（从1→2→4→…→131072） - 预分配：
s := make([]string, 0, len(logs))→ 零次扩容，无额外拷贝
真实压测中，后者在GC压力、分配延迟、CPU缓存命中率上均有显著优势。尤其当切片元素是结构体或指针时，复制开销更不可忽视。
真正容易被忽略的点是：扩容公式本身不难记，但cap的“起点”取决于你如何创建切片——[]T{}、make(T, 0)、make(T, 0, N)三者cap初始值不同，直接影响后续扩容节奏。写性能敏感代码前，务必用fmt.Printf("len=%d cap=%d\n", len(s), cap(s))确认初始状态。
