前两天有朋友在群里贴了一段代码创建一个 cap 为 1024 的 int slice往里面 append 一个元素然后打印 cap(s)。他一脸困惑为什么输出是 1536而不是他背的八股文里算出来的 1280。按照他背的规则容量超过 1024 之后应该按 1.25 倍扩容1024 加 25% 正好是 1280怎么就多出来 256我看了眼他用的 Go 版本1.21。只能告诉他你背的扩容规则是 Go 1.18 之前的老皇历了。从 Go 1.18 开始slice 的扩容算法换了一套阈值从 1024 降到了 256而且最终容量还受内存对齐影响。光靠“小于 1024 翻倍大于 1024 加 25%”已经算不准了。这篇文章我就从源码和实测两个维度把新扩容机制彻底讲透旧算法是怎么来的新算法改了什么为什么最终 cap 不是公式算出来的那个数以及这套新机制对日常开发、性能优化和面试回答到底有什么影响。不管你是刚学 Go 的新手还是背过八股文但好久没翻源码的老手这篇文章都值得看完。1. 旧版扩容规则到底哪里过时了1.1 你背的那套八股文长什么样先来还原一下大多数人背的版本。Go 1.18 之前的runtime.growslice扩容计算部分大概是这样的我省略了内存对齐部分只看核心逻辑// go1.16 时代 runtime/slice.go 中的扩容计算逻辑简化 func growslice(old slice, cap int) slice { newcap : old.cap doublecap : newcap newcap if cap doublecap { newcap cap } else { if old.cap 1024 { newcap doublecap } else { for newcap cap { newcap newcap / 4 } } } // ... 后面还有内存对齐等操作 }翻译成人话就是三条规则如果需要的容量比当前容量两倍还大直接按需要的容量来。如果当前容量小于 1024扩容后容量等于当前容量的两倍。如果当前容量大于等于 1024循环增加 1/4直到满足要求。所以经典面试答案是小于 1024 翻倍大于等于 1024 就 1.25 倍。这套规则从 Go 1.0 时代就存在一直沿用到 Go 1.17背了十几年确实非常稳定。1.2 从 Go 1.18 开始事情变了Go 1.18 的发布说明里提到了growslice的行为变更这是比较少见的——官方专门为一个扩容算法写进 release notes说明这个改动影响面不小。新算法的核心逻辑变成了这样// go1.21 时代 runtime/slice.go 中的扩容计算逻辑简化 func growslice(old slice, cap int) slice { newcap : old.cap doublecap : newcap newcap if cap doublecap { newcap cap } else { const threshold 256 if old.cap threshold { newcap doublecap } else { for 0 newcap newcap cap { newcap (newcap 3*threshold) / 4 } if newcap 0 { newcap cap } } } // ... 内存对齐逻辑 }对比一下就能看出两个关键变化第一翻倍的阈值从 1024 降到了 256。当前容量小于 256 时依然翻倍但超过 256 之后就不再用简单的 1.25 倍循环了。第二大容量时的增长公式从newcap newcap / 4改成了newcap (newcap 3*threshold) / 4也就是newcap newcap/4 192。多出来的这 192就是“平滑过渡”的关键。所以以后面试再问扩容机制你背“小于 1024 翻倍”不是完全错但已经过时了。现在的正确答案应该是小于 256 翻倍大于等于 256 时按newcap newcap/4 192迭代增长。1.3 为什么官方要改这个公式官方源码里给了注释原文大意是这个公式让 slice 从 2 倍增长平滑过渡到 1.25 倍增长避免在某个阈值附近出现增长率的突然跳变。旧规则的问题在于容量 1023 时扩容直接翻倍到 2046容量 1024 时扩容却只到 1280差了将近 800。也就是说辛辛苦苦把容量磨到 1024反而享受不到接近翻倍的红利了增长率从 100% 直接掉到 25%非常突兀。这种“突变”会导致容量增长的连续性很差在某些场景下会多分配不少内存。新规则把过渡点从 1024 提前到了 256并且用带线性偏移的公式抹平曲线。在 256 附近时增长率接近 2 倍容量越大增长率越接近 1.25 倍中间是平滑下降的而不是跳崖式下跌。这个设计思想其实挺优雅的本质上是给扩容节奏加了一个“阻尼”让内存增长更可控。2. 新扩容算法的源码拆解threshold256 与增长公式2.1 growslice 核心计算逻辑我直接把 Go 1.21 里growslice的扩容计算段贴出来加上注释func growslice(et *_type, old slice, cap int) slice { newcap : old.cap doublecap : newcap newcap // 一次性追加特别多元素时需要的容量直接超过两倍 // 这时候再按倍数算没意义直接设置成所需容量。 if cap doublecap { newcap cap } else { const threshold 256 // 小容量阶段继续走翻倍策略保持频繁扩容时的均摊效率。 if old.cap threshold { newcap doublecap } else { // 大容量阶段进入平滑增长。 // 每次增加 newcap/4同时额外加 192也就是 3*threshold/4。 for 0 newcap newcap cap { newcap (newcap 3*threshold) / 4 } // 理论上是 newcap 加着加着溢出了兜底直接取要求容量。 if newcap 0 { newcap cap } } } // ... 下方还有根据元素大小计算内存、roundupsize 对齐等逻辑 }注意函数签名里的cap参数它不是旧容量而是追加后所需的最小容量即old.len 追加元素个数。newcap才是最终扩容出来的容量初始值等于旧容量。这个细节很多人会搞混。举个例子你有一个len100, cap100的 sliceappend 1 个元素需求的cap就是 101。但newcap是从 100 开始的先看 101 是否大于 200doublecap不是再判断 100 小于 256于是直接翻倍到 200。所以最终 cap 是 200。2.2 从 2 倍到 1.25 倍的平滑过渡是怎么实现的很多人第一次看到newcap (newcap 3*threshold) / 4会觉得莫名其妙为什么是3*threshold/4我拆开算一下你就明白了newcap (newcap 768) / 4等价于newcap newcap/4 192也就是说每次循环至少增加 25%同时额外增加 192。这个 192 就是“平滑过渡”的功臣。假设当前容量是 256需求容量是 257第一次迭代newcap 256 256/4 192 256 64 192 512直接翻倍。如果当前容量是 1024newcap 1024 256 192 1472增长率约 43.75%介于 2 倍和 1.25 倍之间。如果当前容量是 4096newcap 4096 1024 192 5312增长率约 29.69%逐渐向 25% 靠拢。当前容量越大那 192 的影响越小增长率越接近 25%。所以这个公式本质上是给大容量时的增长率加了一个“起步偏移”让容量刚突破 256 时不至于立刻掉到 25%而是先温和地多涨一点。这就是官方注释里说的“smooth-ish transition”。为什么阈值选 256 而不是 1024官方注释没有给具体解释。但从实际效果看256 更符合大多数业务 slice 的容量分布——大部分 slice 容量根本到不了 1024在 256 附近就完成多次扩容了。把过渡点提前能让更多 slice 享受到平滑增长而不是在 1024 处撞上一堵墙。2.3 边界条件与溢出保护新代码里有两个细节容易忽略一个是for 0 newcap newcap cap另一个是if newcap 0 { newcap cap }。第一个条件里的0 newcap不是为了判断容量为正而是防溢出。newcap是 int 类型当它接近MaxInt时newcap 3*threshold可能溢出变成负数。一旦 newcap 变成负数newcap cap依然成立循环就会无限加下去。所以0 newcap相当于一个保险丝newcap 一旦溢出为负就立刻停。第二个判断同理。极端情况下如果newcap加过头溢出成负数兜底逻辑直接把它设置成需求容量cap保证不会返回一个负数容量。这两种极端场景在实际业务里几乎碰不到但在写源码的人眼里这是必须处理的边界。这也是 Go runtime 一贯的风格正常路径写得清清楚楚异常路径也留好退路。3. 真正决定 cap 的是 roundupsize内存对齐这层不能漏3.1 为什么 newcap 算完还要再包一层前面所有的公式算出来的newcap只是“理论上的容量”。真正返回给用户的cap是由内存对齐后的字节数除以元素大小得到的。Go 的内存分配器不是按“任意字节数”给你分配内存的而是有一套预先定义好的 size class 尺寸表。你申请 4104 字节分配器不会真给你 4104 字节而是向上取整到离 4104 最近的那个 size class比如 4352 或者 4096 附近更大的档位。这样做是为了减少内存碎片也方便分配器做内存块管理。这个逻辑在growslice后半段// 简化版以 64 位平台 int 类型为例 switch { case et.size goarch.PtrSize: lenmem uintptr(old.len) * et.size newlenmem uintptr(cap) * et.size capmem roundupsize(uintptr(cap) * et.size) overflow capmem maxAlloc cap int(capmem / et.size) }注意最后一行cap int(capmem / et.size)。capmem 是对齐后的字节数除以元素大小才是最终暴露给用户的 cap。所以最终 cap 值是“对齐后字节数”倒推出来的而不是公式直接算出的 newcap。3.2 roundupsize 与 size class 的实际作用roundupsize的简化逻辑大致是这样func roundupsize(size uintptr) uintptr { if size _MaxSmallSize { if size 1024-8 { // 小对象按 8 字节步进查找 size class return uintptr(class_to_size[size_to_class8[divRoundUp(size, 8