Go 切片 append 后为什么另一个切片内容也变了

Go 里最容易让人误判的一类切片问题是：对一个切片执行 append 后，另一个看似独立的切片内容也变了。关键不在 append 会不会“复制切片”，而在它是否还有足够的容量复用同一个底层数组。容量够，写入可能联动；容量不够，运行时才会分配新的数组。

先把切片值与底层数组的关系看清楚

可以把切片理解成一个小描述符：它记录底层数组的起始位置、当前长度 len 和从起始位置算起的容量 cap。切片赋值只复制这个描述符，不会复制数组元素；因此 b := a 后，a 和 b 仍然指向同一片数据。

排查时先打印 len 和 cap，再看两个切片的起始位置是否来自同一个数组。不要把“变量名不同”当成数据已经隔离。

用容量足够的例子复现内容联动

下面的例子故意让 left 还有可用容量，再从它的尾部切出 right。这里的三个索引写法把容量限制在当前长度，便于展示；它没有复制底层数组。

package main

import "fmt"

func main() {
	// 预留容量，让 append 可以在原数组中写入。
	base := make([]int, 2, 4)
	base[0], base[1] = 10, 20
	left := base[:1]
	right := base[1:2:2]

	// left 的 cap 为 4，追加元素时仍可能复用 base。
	left = append(left, 99)
	fmt.Println("left:", left, "right:", right)
}

输出中的 right 会看到 99，因为 left 的第二个元素正好写进了 right 所覆盖的数组位置。若 right 仍有更长的长度，或者后续把它扩展到可见范围，也会观察到同一写入。

区分扩容分支与共享分支

append 的返回值代表追加后的切片。若原切片容量不足，运行时会准备新的底层数组，返回值指向新数组；如果容量足够，则可能直接写入原数组。具体扩容策略由实现决定，代码不应依赖某个增长倍数。

因此，“我给切片 append 了一个元素”本身不能说明有没有扩容。更可靠的判断是：记录追加前的 len/cap，确认被写入的位置是否在另一个切片可见范围内，并把结果赋回原变量。

需要隔离时明确复制边界

如果业务要求修改副本不能影响源切片，就显式复制元素。传统写法适合兼容较早的 Go 环境：

// CloneInts 返回独立数组，源切片后续修改不会改动副本。
func CloneInts(src []int) []int {
	dst := make([]int, len(src)) // 长度相同，避免复制后多出无效零值。
	copy(dst, src)               // copy 只复制元素，不共享 dst 的底层数组。
	return dst
}

使用支持它的 Go 版本时，也可以用 slices.Clone(src) 表达同样的意图。若只是想限制一个切片后续 append 对原数组的影响，可以使用三索引切片收紧容量，例如 isolatedView := src[:len(src):len(src)]；但这只限制扩展，不会复制已有元素，不能替代 copy。

相关问题

为什么换一个变量名仍然会互相影响？

变量名只改变了切片描述符的存放位置，赋值并不会复制底层数组。需要数据隔离时必须复制元素。

只比较两个切片的 len 能判断是否共享吗？

不能。len 只表示可见元素数量，还要结合起始位置、cap 和实际修改的数组区间判断。

append 后如何避免拿到旧的切片？

始终写成 s = append(s, value)，不要假定追加一定在原变量对应的存储上完成；若要求独立数据，再先复制。