slice扩容触发条件是len(s) == cap(s)，即当前长度等于容量时append才会分配新底层数组并复制元素。
slice扩容触发条件是什么
Go 里 append 操作不总是扩容，只在底层数组容量不足时才触发。判断依据是：len(s) 成立就不扩容；一旦 <code>len(s) == cap(s)，append 就必须分配新底层数组。
常见错误现象：反复 append 同一个 slice 却没预估容量，导致多次内存分配和拷贝，性能骤降。
- 小 slice（
cap < 1024）：新cap翻倍，比如从 4→8、512→1024 - 大 slice（
cap >= 1024）：按 1.25 倍增长，向上取整到 8 字节对齐，比如 2048→2560、3000→3752→3760 - 空 slice（
cap == 0）：首次append直接分配 1 个元素空间（不是 0），后续按上述规则增长
runtime.growslice 的实际行为怎么看
别直接啃 src/runtime/slice.go 里的 growslice 函数——它做了大量边界检查、溢出防护和内存对齐处理，但核心扩容逻辑就藏在那几行计算新容量的代码里。
使用场景：当你看到 panic: runtime error: makeslice: len out of range 或 GC 频繁抖动，很可能就是扩容路径上某次计算溢出了。
立即学习“go语言免费学习笔记（深入）”；
- 新容量计算不是简单乘法，而是调用
memmove前先走roundupsize（在malloc.go中），确保满足内存分配器要求 -
growslice返回的是新底层数组指针，原数组不会被复用，哪怕只差 1 个元素空间 - 如果
append的元素类型含指针（如[]*int），扩容还会触发写屏障（write barrier）逻辑，影响 GC 性能
如何验证当前 slice 的扩容行为
靠猜不如看实锤。最直接的方式是用 unsafe.Sizeof + reflect 观察底层数组地址变化，或用 pprof 抓内存分配热点。
性能影响明显：一次扩容可能引发 KB~MB 级内存拷贝，尤其在循环中无意识触发时。
- 用
fmt.Printf("len=%d cap=%d data=%p\n", len(s), cap(s), &s[0])打印地址，连续append后对比是否变化 - 启动程序加
-gcflags="-m"可看到编译器是否将 slice 逃逸到堆，间接反映扩容压力 - 避免在 hot path 中用
append(s, x...)扩展变长参数，改用预分配的make([]T, 0, N)
为什么预分配容量不总能绕过扩容
预分配（make([]T, 0, N)）能消除大部分扩容，但 runtime 仍可能“不按套路出牌”。
容易踩的坑：以为 cap=1000 就永远不扩容，结果发现第 1001 次 append 还是分配了新内存——因为 len 达到 cap 的瞬间就触发了。
- 扩容阈值是
len == cap，不是len > cap，所以最后一个可用位置填完就扩 - 如果用
copy或append多个元素（如append(s, a...)），一次性超过当前cap，runtime 会按需算出足够大的新容量，可能远超你预期 -
append的第二个参数如果是切片（append(s, t...)），其长度参与总长度计算，但不会提前暴露 t 的底层数组，所以无法静态预判是否扩容
真正难的不是看懂源码，是意识到 slice 的“不可见状态”——你永远不知道下一次 append 是 O(1) 还是 O(n)，除非你盯住 len 和 cap 的实时关系。
