Go语言slice扩容非固定倍数：容量＜1024时翻倍，≥1024时按1.25倍渐进增长；若需容量＞原容量×2则直接取需容量；最终容量还需经内存对齐调整。
Go 语言 slice 的扩容规则在 2026 年仍沿用 Go 1.20+ 稳定后的机制，**不是固定 1.5 倍，也不是简单 2 倍**——它分段、有阈值、受内存对齐影响，核心逻辑由 growslice 函数实现。
扩容分段策略：小于 1024 用翻倍，大于等于 1024 用 1.25 倍渐进增长
这是当前（Go 1.20–1.23）实际生效的规则，未发生颠覆性变更：
- 若原切片 容量 ：新容量 = 原容量 × 2（即 doublecap）
- 若原切片 容量 ≥ 1024：进入循环增长逻辑：
newcap += newcap / 4（等价于每次 ×1.25），直到newcap ≥ 所需最小容量 - 注意：这个“1.25 倍”是**下限逼近**，不是一步到位。例如从 1024 扩到 1282，需迭代 2 次（1024→1280→1600），而目标只需 1282，则停在 1280（再经内存对齐后可能为 1280 或 1296）
关键例外：当所需容量远超 doublecap 时，直接取所需容量
源码中第一判断优先级最高：
if cap > doublecap { newcap = cap }- 也就是说：如果你 append 一堆元素，导致「需要的总容量」已经超过「原容量 × 2」，Go 就不折腾倍增了，直接按需分配
- 典型场景：空切片
make([]int, 0)一次性 append 2000 个元素 → 新容量就是 2000（非 2048）
内存对齐：真实 cap 往往比计算值略大
扩容计算出的 newcap 只是理论值，最终 cap 还要过一道关：
→ 转成字节数（newcap × elemSize）→ 调用 roundupsize() → 按 runtime 内存分配器的 size class 对齐 → 再换算回元素个数
- 例如 int64 切片（每个 8 字节），计算得 newcap = 7 → 字节数 = 56 →
roundupsize(56)返回 64 → 最终 cap = 64 ÷ 8 = 8 - 这也是为什么
[]int{1,2} → append(...,4,5,6)后 cap=6（不是 4 或 8）：5×8=40 → 对齐到 48 → 48÷8=6 - 对齐规则由
class_to_size表决定，小尺寸（≤1024 字节）对齐粒度细，大尺寸逐步变粗
版本确认与验证建议
截至 2026 年初，主流发行版（Go 1.21.6 / 1.22.10 / 1.23.4）均未修改 src/runtime/slice.go 中的 growslice 主干逻辑。你可以这样验证：
- 查看本地 Go 源码：
$GOROOT/src/runtime/slice.go，搜索const threshold = 256和old.cap （注意：阈值 256 是内部过渡参数，对外仍是 1024 分界） - 实测命令：
go version && go run -gcflags="-S" main.go | grep growslice观察是否调用该函数 - 写最小 case 打印 len/cap，比对结果与
growslice逐行推演是否一致（推荐用 int64 避免指针大小干扰）
