append触发扩容的唯一条件是len(s)==cap(s)；空slice首次append分配1个元素空间；小容量（
append 触发扩容的唯一条件是 len(s) == cap(s)
只要当前长度还没撑满容量，append 就不会分配新底层数组，直接在原数组末尾写入。这是最常被误解的一点——很多人以为“只要 append 就会扩容”，结果在循环里反复 append 却没预估容量，导致几十次内存重分配和拷贝。
- 空 slice（
cap == 0）首次append会直接分配 1 个元素空间，不是 0 len(s) 时，无论 <code>cap是 5 还是 5000，都不会扩容- 只有
len(s) == cap(s)成立的瞬间，下一次append才真正触发扩容逻辑
扩容倍数不是固定 2 倍，而是分段策略 + 对齐处理
Go runtime 的扩容策略藏在 src/runtime/slice.go 里，实际行为比“翻倍”更精细：小 slice 讲效率，大 slice 讲内存利用率，且所有新容量都会向上对齐到 8 字节边界。
cap ：新 <code>cap=old cap * 2（例如 512 → 1024）-
cap >= 1024：每次增长约 25%，即new cap = old cap + old cap / 4，再向上取整到 8 的倍数（例如 2048 → 2560，3000 → 3760） - 如果一次性
append多个元素（如append(s, a, b, c...)），runtime 会先算出“期望容量”，若该值 > 当前cap，就按上述规则扩到 ≥ 期望容量的最小合法值
make 初始化时指定 cap 是性价比最高的优化手段
靠 runtime 自动扩容永远有代价：拷贝、分配、GC 压力。而提前用 make([]T, len, cap) 预留空间，几乎零成本。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 已知最终长度约 200？直接
make([]int, 0, 256)，后续 256 次append全部免扩容 - 从已有数组切片（如
data[100:200]）再追加数据？注意它的cap可能远大于len，但若不够，扩容后就脱离原数组，失去共享优势 - 错误示范：
s := make([]int, 0); for i := 0; i —— 至少触发 10 次扩容，底层数组拷贝累计超 100KB
用 len 和 cap 差值判断是否“快满了”，比猜更可靠
别凭经验估算“差不多该扩容了”。运行时看 cap - len 才是真实余量；调试时打印它，比看 len 本身更有意义。
立即学习“go语言免费学习笔记（深入）”；
- 常见陷阱：把
cap当成“最大允许长度”，误以为len == cap是危险状态——其实它是扩容临界点，不是错误状态 - 并发场景下尤其要注意：多个 goroutine 共享一个 slice 并
append，即使cap足够，也可能因竞态导致数据覆盖或 panic - 调试技巧：在关键路径加
fmt.Printf("len=%d cap=%d diff=%d\n", len(s), cap(s), cap(s)-len(s))，几秒内就能定位是不是扩容成了瓶颈
真正难的不是记住扩容公式，而是意识到：slice 的“自动”背后全是显式内存操作。每次 append 都可能引发一次 malloc + memmove，而你往往只在 pprof 里看到它已经晚了。
