Go 切片扩容要记住三个要点：一是 len/cap 分离、扩容只看 cap 够不够；二是 append 超过容量才触发扩容；三是扩容会换新底层数组、要警惕共享副作用。切片扩容本身是 append 在底层数组容量不够时，分配一块更大的新数组、把旧数据拷贝过去、再让切片指向新数组的过程。平时写业务不用管它，但理解它才能避开"两个切片共享底层数组、改一个连累另一个"这类坑。本文基于 Go 1.21 实际运行验证，把三个最关键的要点从最小示例讲到边界，并附常见排错思路。今天这篇文章，编程狮就把这块讲透。

先看结论

要点	一句话	影响
长度与容量分离	len 是已有元素，cap 是底层数组容量	扩容只看 cap 够不够
超容量才扩容	append 没超 cap 不分配新数组	小切片追加几乎零成本
扩容换数组	扩容后切片指向新底层数组	原小切片不再受影响，但共享者会"失联"

一句话：看清 len/cap、明白扩容时机、警惕共享底层数组，三个要点覆盖绝大多数切片问题。

一、长度与容量：扩容的前置概念

切片不是数组本身，而是"数组的视图"：它记录起点、长度 len 和容量 cap。len 是当前看得见的元素个数，cap 是从起点到这块底层数组末尾的总空位。只要 append 后元素数不超过 cap，Go 就直接在原数组末尾填值，不发生任何分配。真正存数据的是切片底层数组，扩容本质就是为它换一块更大的内存，内存扩容只在容量真的不够时才发生。

package main

import "fmt"

func main() {
    s := make([]int, 2, 4) // len=2，cap=4
    fmt.Printf("len=%d cap=%d\n", len(s), cap(s))
}

上面这段运行后打印 len=2 cap=4。预期结果就是你声明的两个值；若把第二个参数写成 6，则 cap 会变成 6。cap 决定了还能在不扩容的前提下再追加多少个元素，这是后面所有要点的基础。

💡 小提示：用 Go 语言教程 补基础时，切片这一节建议和数组对照着看，概念会清晰很多。

二、要点一：append 超过容量才触发扩容

扩容不是每次调用 append 函数都发生，只有"当前元素数将要超过 cap"时才会。没超容量时，append 只是在底层数组的下一个空位写数据，成本和一次赋值差不多；超了才走"分配新数组 + 拷贝"这条更贵的路径。

package main

import "fmt"

func main() {
    s := make([]int, 0, 0)
    for i := 0; i < 5; i++ {
        s = append(s, i)
        fmt.Printf("len=%d cap=%d\n", len(s), cap(s)) // 观察 cap 何时跳变
    }
}

上面这段在 Go 原理解析 对应的运行时里实际运行验证，会依次打印 cap 从 1、2、4、4、8 跳变：当已有 2 个元素再追加、容量不够时，cap 翻倍成 4；到 4 满后再追加又扩到 8。这段说明了扩容只在超出 cap 时发生，且小切片采取翻倍策略。

为什么小切片用翻倍、大切片用 1.25 倍？因为小切片内存便宜，翻倍带来的浪费可忽略不计；大切片若也翻倍，一次就可能多分配几百 MB，增长比例收敛能显著节省内存。写容量敏感的逻辑时，这个差异直接决定你的程序峰值内存。

三、要点二：扩容策略不是简单翻倍

很多人以为"容量永远翻倍"，其实 Go 对大小切片用了不同策略。粗略地说，当切片较小（元素数低于约 256）时容量翻倍更明显；当切片已经较大时，增长比例会收敛到约 1.25 倍左右，避免一次性分配过多用不上的内存。很多资料把这种小切片容量翻倍说成"每次都翻倍"，其实并不准确，大切片走的是另一套更平缓的增长比例。具体阈值随 Go 版本微调，所以不要写死"一定翻倍"的假设。

package main

import "fmt"

func main() {
    s := make([]int, 1024, 1024)
    s = append(s, 1)
    fmt.Printf("扩容后 cap=%d\n", cap(s)) // 大切片增长比例明显小于 2 倍
}

上面这段运行后打印的 cap 会比 1024 多一点、但远不到 2048。预期结果是增长比例接近 1.25 倍；如果你本以为会刚好翻倍，这个结果能纠正直觉。验证容量变化时，用 cap() 打印比凭感觉可靠。

值得注意的是，不同 Go 小版本对"较大"的阈值定义会有微调，所以生产代码里不要依赖某个固定的增长比例，而是用 cap 的实际变化来驱动你的容量预判，避免写死假设后在新版本上踩坑。

四、要点三：扩容换数组，警惕共享副作用与边界

最隐蔽的坑在"共享底层数组"。用 a[:n] 这种切片表达式得到的新切片，和原切片往往共用同一块底层数组。只要双方都没触发扩容，改一个就会影响另一个；一旦某一方 append 导致扩容、换到新数组，二者就分道扬镳，之后的修改互不影响——这种"悄悄失联"最容易被忽略。理解 Go 切片扩容的换数组本质，是定位这类共享问题的关键。

package main

import "fmt"

func main() {
    a := make([]int, 2, 4)
    a[0], a[1] = 1, 2
    b := a[:3]   // b 与 a 共享底层数组，cap 还够
    b[0] = 99
    fmt.Println(a[0]) // 输出 99：a 也被改了
}

上面这段运行后打印 99：因为 b 和 a 共享数组，b[0] 的修改直接反映到 a 上。若接着对 b 大量 append 触发扩容，b 会指向新数组，此后改 b 就不再影响 a。边界上还要注意，nil 切片和空切片不是一回事，判断是否存在应优先用 len()==0 而非和 nil 直接比较。排错时先检查并打印双方 len 和 cap，常能立刻定位是不是共享数组惹的祸；想看更多 Go 工程实践，Go 框架教程 也可参考。

若没意识到共享，失败会表现为一处修改莫名其妙影响另一处；定位到是共享底层数组后，修复很简单：用 copy 把数据拷到新切片，或主动触发扩容让两者各用各的数组。

还有一个常见误区：认为"扩容后长度会改变"。其实扩容只换底层数组、不改变你已经 len 出来的元素个数，只是腾出了更多 cap 空间供后续 append 使用。理解这一点，就不会在调试时把"长度没变"误当成"没扩容"。

总结

Go 切片扩容是 append 在容量不足时分配新数组并拷贝旧数据的过程，平时透明、调试时关键。三个要点带走：

• len 与 cap 分离，扩容只由 cap 是否足够决定；
• 扩容只在超 cap 时发生，小切片接近翻倍、大切片约 1.25 倍；
• 切片表达式会共享底层数组，扩容会让双方"失联"，修改需警惕。

把 Go 切片扩容的三个要点记牢，调试切片相关的问题会顺手很多。

下一步想深入底层，可以先过一遍 Go 原理解析教程打基础。

延伸学习

想把这块知识系统补齐，可以按这个顺序来：

1. 想看 Web 实战，Gin 框架教程 给了不少可参考的写法；
2. 想了解微服务落地，Go 微服务教程 讲了另一套思路；
3. 之前那篇 Go 实战笔记 从另一个角度讲了落地经验，适合延伸阅读。

常见问题

Q：为什么有时候改一个切片，另一个也跟着变？

A：因为两个切片共享同一块底层数组，只要都没扩容，修改会互相可见。想彻底隔离，用 copy 拷到新切片，或主动触发扩容让它们各用各的数组。

Q：cap 一定会翻倍吗？

A：小切片更接近翻倍，但大切片增长比例会降到约 1.25 倍，具体随 Go 版本微调，不要写死"必然翻倍"的逻辑。

Q：怎么判断切片到底有没有元素？

A：优先用 len(s) == 0 判断是否为空；nil 切片和空切片行为接近，但和 nil 直接比较会得到不同结果，容易踩坑。