Go slice 的 append 陷阱:共享底层数组导致的数据串改写 Go 的人几乎都踩过这个坑:把一个 slice 传进函数、或者用append往里塞元素,结果另一个看似不相干的 slice 数据莫名其妙变了。定位半天,最后发现两个 slice 底层指向同一块内存。这篇把 slice 的底层结构讲清楚,再一步步演示 append 什么时候会共享、什么时候会分家,以及怎么写才安全。先看一段会出问题的代码packagemainimportfmtfuncmain(){base:[]int{1,2,3,4,5}// 取前 3 个,想单独处理,不影响 basesub:base[:3]subappend(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):从指针位置到底层数组末尾的元素个数用内置函数打印出来看:base:[]int{1,2,3,4,5}sub:base[:3]fmt.Printf(base len%d cap%d\n,len(base),cap(base))// len5 cap5fmt.Printf(sub len%d cap%d\n,len(sub),cap(sub))// len3 cap5关键就在这里: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:分配一块更大的新数组,拷贝旧数据过去,从此分家,后续互不影响。验证分家的情况:base:[]int{1,2,3}sub:base[:3]// len3 cap3,已经满了subappend(sub,100)// 超容量,触发扩容,分配新数组sub[0]999fmt.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 倍,并且最终还会做内存对齐。s:make([]int,0)prev:cap(s)fori:0;i2000;i{sappend(s,i)ifcap(s)!prev{fmt.Printf(len%d 时扩容到 cap%d\n,len(s),cap(s))prevcap(s)}}跑一下会看到容量增长在后期明显放缓。结论:永远不要在代码里硬编码「扩容后 cap 一定是多少」,这不是稳定契约。如果你提前知道大概要放多少元素,直接make([]int, 0, n)预分配容量,既避免多次扩容拷贝,也让性能更可控。真正安全的三种写法写法一:三索引切片,把容量卡死base[low:high:max]这个三索引语法能显式限制新 slice 的容量,让它「一 append 就必然扩容分家」:base:[]int{1,2,3,4,5}sub:base[:3:3]// low0 high3 max3 → len3 cap3subappend(sub,100)// cap 已满,立即扩容,不碰 basefmt.Println(sub :,sub)// [1 2 3 100]fmt.Println(base:,base)// [1 2 3 4 5] ← 安全当你要把一个大 slice 的子片段交给别人处理、又担心对方 append 污染原数组时,[:n:n]是最省事的护身符。写法二:需要独立副本就显式 copy如果子 slice 后续要长期持有、反复修改,直接拷一份最清晰:base:[]int{1,2,3,4,5}sub:make([]int,3)copy(sub,base[:3])// 深拷贝前 3 个元素到独立数组subappend(sub,100)sub[0]999fmt.Println(base:,base)// [1 2 3 4 5] ← 完全隔离注意copy只拷贝元素值。如果元素本身是指针或含指针的结构体,拷的是指针,指向的对象还是共享的——这是另一层「浅拷贝」陷阱,视需求再决定要不要深拷。写法三:函数入参别假设「传了就安全」Go 里 slice 是值传递,但传的是那个「指针lencap」的结构体副本,底层数组仍是同一个。所以函数内 append 一样可能改到调用方:funcaddTag(tags[]string){tagsappend(tags,extra)// 若 cap 有富余,会写进调用方的底层数组}funcmain(){tags:make([]string,2,4)// 故意留出容量tags[0],tags[1]a,baddTag(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。
