Go slice 的 append 陷阱:共享底层数组导致的数据串改
写 Go 的人几乎都踩过这个坑:把一个 slice 传进函数、或者用 append 往里塞元素,结果另一个看似不相干的 slice 数据莫名其妙变了。定位半天,最后发现两个 slice 底层指向同一块内存。这篇把 slice 的底层结构讲清楚,再一步步演示 append 什么时候会共享、什么时候会分家,以及怎么写才安全。
先看一段会出问题的代码
go
package main
import "fmt"
func main() {
base := []int{1, 2, 3, 4, 5}
// 取前 3 个,想单独处理,不影响 base
sub := base[:3]
sub = append(sub, 100) // 期望 sub 变成 [1 2 3 100],base 不动
fmt.Println("sub :", sub) // [1 2 3 100]
fmt.Println("base:", base) // [1 2 3 100 5] ← base[3] 被改成了 100!
}base 的第 4 个元素被悄悄改掉了。原因是 sub 和 base 共享同一块底层数组,append 发现 sub 还有剩余容量,就直接写进了 base[3] 的位置。
slice 的三个字段:指针、长度、容量
Go 的 slice 本质是一个结构体,包含三个字段:
- 指针(array):指向底层数组的某个位置
- 长度(len):当前 slice 可见的元素个数
- 容量(cap):从指针位置到底层数组末尾的元素个数
用内置函数打印出来看:
go
base := []int{1, 2, 3, 4, 5}
sub := base[:3]
fmt.Printf("base len=%d cap=%d\n", len(base), cap(base)) // len=5 cap=5
fmt.Printf("sub len=%d cap=%d\n", len(sub), cap(sub)) // len=3 cap=5关键就在这里:sub 的长度是 3,但容量是 5 ------因为它和 base 共用底层数组,从索引 0 一直数到底层数组末尾还有 5 个位置。所以 append(sub, 100) 时,cap(5) > len(3),有富余空间,append 不会分配新数组,而是直接把 100 写进底层数组索引 3 的位置,也就是 base[3]。
append 什么时候分家、什么时候共享
规则很简单:append 后新长度是否超过原容量。
- 新 len ≤ cap:原地写入,继续共享底层数组,可能污染其他 slice。
- 新 len > cap:分配一块更大的新数组,拷贝旧数据过去,从此分家,后续互不影响。
验证分家的情况:
go
base := []int{1, 2, 3}
sub := base[:3] // len=3 cap=3,已经满了
sub = append(sub, 100) // 超容量,触发扩容,分配新数组
sub[0] = 999
fmt.Println("sub :", sub) // [999 2 3 100]
fmt.Println("base:", base) // [1 2 3] ← base 完全没变因为 sub 容量已满,append 触发扩容,sub 指向了全新的底层数组,改 sub[0] 再也影响不到 base。
这就是最坑的地方:同样一行 append 代码,行为取决于运行时的容量,有时污染有时不污染,导致 bug 时隐时现,极难复现。
扩容策略:不要依赖具体倍数
很多老文章说「slice 扩容按 2 倍增长」,这只在小切片时近似成立。Go 1.18 之后扩容逻辑调整过:元素较少时约 2 倍,超过一定阈值(旧版本是 1024)后增长因子逐步降到约 1.25 倍,并且最终还会做内存对齐。
go
s := make([]int, 0)
prev := cap(s)
for i := 0; i < 2000; i++ {
s = append(s, i)
if cap(s) != prev {
fmt.Printf("len=%d 时扩容到 cap=%d\n", len(s), cap(s))
prev = cap(s)
}
}跑一下会看到容量增长在后期明显放缓。结论:永远不要在代码里硬编码「扩容后 cap 一定是多少」 ,这不是稳定契约。如果你提前知道大概要放多少元素,直接 make([]int, 0, n) 预分配容量,既避免多次扩容拷贝,也让性能更可控。
真正安全的三种写法
写法一:三索引切片,把容量卡死
base[low:high:max] 这个三索引语法能显式限制新 slice 的容量,让它「一 append 就必然扩容分家」:
go
base := []int{1, 2, 3, 4, 5}
sub := base[:3:3] // low=0 high=3 max=3 → len=3 cap=3
sub = append(sub, 100) // cap 已满,立即扩容,不碰 base
fmt.Println("sub :", sub) // [1 2 3 100]
fmt.Println("base:", base) // [1 2 3 4 5] ← 安全当你要把一个大 slice 的子片段交给别人处理、又担心对方 append 污染原数组时,[:n:n] 是最省事的护身符。
写法二:需要独立副本就显式 copy
如果子 slice 后续要长期持有、反复修改,直接拷一份最清晰:
go
base := []int{1, 2, 3, 4, 5}
sub := make([]int, 3)
copy(sub, base[:3]) // 深拷贝前 3 个元素到独立数组
sub = append(sub, 100)
sub[0] = 999
fmt.Println("base:", base) // [1 2 3 4 5] ← 完全隔离注意 copy 只拷贝元素值。如果元素本身是指针或含指针的结构体,拷的是指针,指向的对象还是共享的------这是另一层「浅拷贝」陷阱,视需求再决定要不要深拷。
写法三:函数入参别假设「传了就安全」
Go 里 slice 是值传递,但传的是那个「指针+len+cap」的结构体副本,底层数组仍是同一个。所以函数内 append 一样可能改到调用方:
go
func addTag(tags []string) {
tags = append(tags, "extra") // 若 cap 有富余,会写进调用方的底层数组
}
func main() {
tags := make([]string, 2, 4) // 故意留出容量
tags[0], tags[1] = "a", "b"
addTag(tags)
fmt.Println(len(tags), tags) // 2 [a b] ← 长度没变,但底层数组第 3 位已被写入 "extra"
// 后续对 tags 的 append 可能读到这个残留值,行为诡异
}想让函数安全地扩展并返回,标准做法是把结果返回给调用方 ,像标准库那样:tags = addTag(tags),函数内 return append(tags, "extra")。不要指望「函数改了参数外面自动生效」------slice 的 append 语义天生不适合这么用。
小结
- slice 是「指针 + len + cap」的三字段结构,多个 slice 可以共享同一底层数组。
append在 新 len ≤ cap 时原地写入并继续共享,可能污染其他 slice;新 len > cap 时才分配新数组、彻底分家。- 同一行 append 的行为随容量变化,是这类 bug 时隐时现的根源。
- 扩容倍数不是稳定契约,别硬编码;能预估大小就
make([]T, 0, n)预分配。 - 三种安全姿势:切片时用
[:n:n]卡死容量、需要独立副本就copy、函数扩展 slice 一律「return 回去」。
一句话记忆点:只要两个 slice 的 cap 覆盖了同一段内存,append 就是一颗定时炸弹------不确定时,[:n:n] 或 copy。