append只在len(s) == cap(s)且调用时真正触发扩容；此时cap==0→新cap=1，cap<1024→翻倍，cap≥1024→按cap+cap/4向上对齐到元素大小倍数。
append 什么时候真正触发扩容？
只在 len(s) == cap(s) 且调用 append 时触发，不是每次调用都分配新内存。很多人误以为“容量还剩就安全”，结果下一次 append 突然变慢、地址变了——那是因为上一次已把 len 拉到等于 cap，这次才是真正的扩容点。
常见错误现象：
-
cap(s)显示还有 500，但append(s, x)后&s[0]地址变了 → 实际上前一次操作已让len达到cap - 用
make([]int, 0)初始化后循环追加 1000 次，至少触发 10 轮扩容（0→1→2→4→8…），累计拷贝超 100KB 数据 - nil 切片（如
var s []int）首次append必分配，且新容量固定为 1，不是 0
小容量 vs 大容量的扩容倍数怎么算？
Go 的扩容不是简单翻倍，而是分段策略 + 内存对齐，规则藏在 src/runtime/slice.go 里：
-
cap == 0→ 新cap = 1 -
cap < 1024→ 新cap = cap * 2（例如 512 → 1024） -
cap >= 1024→ 新cap = cap + cap/4，再向上取整到 8 字节倍数（例如 2048 → 2560，3000 → 3760） - 若目标容量远超当前值（比如
cap=100但要追加 1000 个），runtime 会跳过倍增逻辑，直接分配 ≥ 目标值的最小合法容量
注意：cap/4 是整数除法，不是浮点运算；最终容量还会被 round up 到元素大小的倍数（[]int64 按 8 字节对齐）。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么预分配 make([]T, 0, n) 最便宜？
靠 runtime 自动扩容永远有代价：堆分配、数据拷贝、GC 压力。而 make([]T, 0, n) 在初始化时就预留底层数组，前 n 次 append 完全零分配、零拷贝。
容易踩的坑：
-
make([]int, 5, 10)创建的是长度为 5、容量为 10 的切片，但你不能直接写s[7] = 42→ panic，因为有效索引范围是[0, len)，不是[0, cap) - 想扩展长度必须用
s = s[:10]或append(s, x)，不能越界赋值 - 预分配后若长期只用小部分长度（比如
cap=1000但实际只存 10 个），会造成内存浪费，尤其在高频创建/销毁场景（如 HTTP handler）
如何验证是否真发生了扩容？
不能只看 len 或 cap 变化，唯一可靠方式是比对底层数组指针：
oldData := &s[0]
s = append(s, x)
newData := &s[0]
if oldData != newData { // 真扩容了 }
注意：
- 对零长度切片取
&s[0]会 panic，需先确保len(s) > 0 - Go 1.21+ 支持
unsafe.SliceData更安全获取底层数组地址，但需导入unsafe - 扩容后旧底层数组若无其他引用，将在后续 GC 中被回收 —— 但别依赖这点做逻辑判断
复杂点在于：相同初始容量、不同追加节奏，可能导致最终底层数组地址完全不同；而共享底层数组的切片（如 s2 := s1 或 s2 := s1[2:4]）改一个就等于改原数组 —— 这些细节一旦忽略，调试时会反复踩坑。
