Go copy 重叠切片时为什么结果仍然可预测

很多人第一次看到 copy(s[1:], s[:5]) 时，会担心后写入的元素把后续源数据覆盖，结果像手写循环那样“越移越乱”。Go 对这种情况有明确语义：copy 支持源切片和目的切片重叠，结果与内存重叠无关；实际复制的元素个数是 len(src) 和 len(dst) 中较小的那个。

先看方向：copy 到底复制了多少元素

判断一条 copy 语句，先不要看底层地址，只看两个问题：目的切片能接收多少个元素，源切片能提供多少个元素。下面的示例中，目的切片长度为 5，源切片长度也为 5，所以返回值是 5。

package main

import "fmt"

func main() {
	data := []int{0, 1, 2, 3, 4, 5}
	// 目的区间从下标 1 开始，源区间从下标 0 开始，两者重叠。
	n := copy(data[1:], data[:5])
	// n 表示实际复制的元素数，不表示 data 的新长度。
	fmt.Println(n, data) // 5 [0 0 1 2 3 4]
}

这里的方向是“把旧数据向右挪一格”。如果写成 copy(data[:5], data[1:])，方向就变成向左挪，结果会是 [1 2 3 4 5 5]。两条语句都合法，区别只在目的区间和源区间的位置。

重叠时为什么不会出现链式污染

切片只是底层数组的一段视图。data[1:] 和 data[:5] 确实可能指向同一个数组，但语言规范规定 copy 的结果不受参数内存重叠影响。可以把它理解为：实现必须先依据复制前的源元素确定这次复制，再写入目的区域，而不是让刚写出的值继续充当后面的源值。

因此，右移一格时，下标 0 到 4 的旧值会分别落到下标 1 到 5；左端原来的下标 0 不会被自动清零。copy 只负责覆盖目的切片能覆盖的范围，数组里其他位置保持原样。

插入和删除：先处理长度，再让 copy 搬数据

copy 不会替目的切片增加长度，所以插入元素时必须先确认容量足够，并把切片重新切到新长度。删除时则把后半段左移，最后缩短长度。

func insertAt(s []int, index, value int) []int {
	// 调用方需要保证 index 在 [0, len(s)] 内且容量足够。
	s = s[:len(s)+1]
	// 目的区间和源区间重叠，copy 会安全地把尾部右移一格。
	copy(s[index+1:], s[index:len(s)-1])
	s[index] = value
	return s
}

func removeAt(s []int, index int) []int {
	// 把删除位置后面的元素向左覆盖，返回实际移动数量可按需忽略。
	copy(s[index:], s[index+1:])
	// 对含指针的元素清理尾部，避免底层数组继续持有对象引用。
	var zero int
	s[len(s)-1] = zero
	return s[:len(s)-1]
}

插入版本的关键是 s[:len(s)+1]：它只改变切片长度，不代表已经分配了新数组。若容量不足，应该先用 append 或重新分配一个更大的切片。删除版本中的尾部清理对 int 没有实际资源意义；如果元素是包含指针的结构体或指针类型，就应写成对应的零值清理逻辑。

四个边界别混在一起

第一，目的切片长度为零时，即使容量还有空间，copy 也复制不了元素；要先重新切片。第二，源或目的为 nil 切片时调用本身安全，返回值为 0。第三，返回值只是本次写入的元素数，不能说明底层数组是否换了，也不会告诉你切片头是否需要重新赋值。第四，重叠语义只解决一次调用内的内存覆盖问题，多个 goroutine 同时读写同一底层数组仍然需要同步。

常见问题

copy 会像 append 一样自动扩容吗？

不会。它只在目的切片现有长度范围内写入；需要增加长度或容量时，要先使用切片表达式、append 或重新分配。

重叠复制需要自己倒序循环吗？

不需要。单次 copy 已定义了重叠情况下的结果；手写循环反而容易因方向错误覆盖源数据。

为什么复制后原切片的开头还保留旧值？

因为目的区间没有覆盖它。copy 只写目的切片，不负责清理目的区间之外的数组元素。

实际排查时，可以把表达式先改写成“目的起点、目的长度、源起点、源长度”四个数字，再取两个长度的较小值。只要同时记住切片共享底层数组，以及 copy 只改元素不改切片头，重叠结果就不会再靠猜。