扩容非固定倍数而是分段策略+内存对齐，Go 1.18起阈值由1024降至256且增长因子动态下降；触发时机为len+新增元素数>cap，非每次append都扩容。
直接说结论：扩容不是固定倍数，而是分段策略 + 内存对齐，且 Go 1.18 起阈值和增长因子都变了；面试时只答“翻倍或 1.25 倍”是扣分项。
扩容触发时机只看 append 时的 len+1 > cap
不是每次 append 都扩容，只在当前长度加 1 超过容量时才调用 runtime.growslice。常见误判是认为“只要 append 就扩容”，其实：
- 若
s := make([]int, 3, 5)，再append(s, 1)（第 4 个元素），len=4 ≤ cap=5，不扩容，仍指向原数组 - 只有第 6 次
append（len=5 → 6）才触发扩容，因为6 > 5 - 即使你
append(s, 1, 2, 3)一次加多个，判断依据仍是len + 新元素个数 > cap
新容量计算逻辑分三档，Go 1.18 是分水岭
旧版（≤1.17）用硬阈值 1024，新版（≥1.18）改用 256，且增长因子动态下降——这是多数人漏掉的关键点：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 期望容量
cap≤ 当前cap * 2：直接取cap * 2 - 当前
cap ：新 <code>cap = cap * 2（如 128 → 256） - 当前
cap ≥ 256：进入循环，每次加cap / 4（即 ×1.25），但实际增长因子随容量增大缓慢收敛，比如：
256 → 320 → 400 → 500 → 625 → 781 → 976 → 1220… 不是简单等比 - 所有结果最后还要做内存对齐（如 64 字节边界），所以实际
cap可能略大于理论值
扩容后原 slice 和新 slice 底层地址一定不同
只要触发了扩容，growslice 必然分配新内存、拷贝老数据，因此：
立即学习“go语言免费学习笔记（深入）”；
- 扩容前后的两个 slice 不再共享底层数组，修改互不影响
- 但要注意：没扩容时（如
s1 := s后append未超 cap），s1和s仍共用同一底层数组，改一个另一个也变 - 验证方式：打印
&s[0]和&newS[0]，地址不同即已扩容 - 这个行为直接影响函数传参、并发写入、深拷贝需求——比如日志聚合中误用未扩容切片，可能引发静默数据污染
真正容易被忽略的是：扩容策略不是纯数学公式，而是编译器与运行时协同的结果；growslice 的源码里有大量边界检查和对齐处理，实际容量往往比“×2 或 ×1.25”算出来的略大。面试时如果能提到“内存对齐”和“Go 1.18 的增长因子渐进变化”，基本就踩中加分点了。
