Go的copy函数对重叠切片有明确定义：按内存地址顺序逐字节复制，若dst起始地址≤src起始地址或dst结束地址≤src起始地址则安全，否则因边写边读导致数据污染。
copy 函数在重叠切片场景下到底怎么复制？
Go 的 copy 对重叠切片有明确定义的行为，不是“未定义”或“看运气”。它按源（src）到目标（dst）的**内存地址顺序逐字节复制**，且行为取决于 src 和 dst 的相对位置——这直接决定是否出现“覆盖后又被读取”的问题。
关键判断逻辑：如果 dst 起始地址 ≤ src 起始地址，或 dst 结束地址 ≤ src 起始地址，则无重叠或低地址先写，安全；否则（dst 起始在 src 区间内），会因边写边读导致数据污染。
-
copy(dst[1:], dst)是典型危险操作：把dst[0]复制到dst[1]，接着dst[1]（刚被改过的值）又被复制到dst[2]，最终整个 dst 变成重复的第一个元素 -
copy(dst, dst[1:])是安全的：先读dst[1]写入dst[0]，再读dst[2]写入dst[1]……不会读到刚写过的位置 - 底层不区分 slice header，只看底层数组指针和长度算出的实际内存范围，所以即使 cap 不同、len 不同，只要底层地址重叠就按内存布局处理
为什么不能依赖 copy 处理原地移动（比如左移/右移）？
因为 copy 不是为原地移位设计的。它只保证“最多复制 min(len(src), len(dst)) 个元素”，但不保证中间状态一致。右移（如 copy(a[1:], a)）必然出错，左移（如 copy(a, a[1:])）才恰好符合安全方向。
- 想实现通用数组左移 n 位？别硬套
copy，用循环或append(a[n:], a[:n]...)更直观可靠 - 想原地反转？
copy完全不适用，必须双指针交换 - 标准库中
bytes.Buffer或strings.Builder的 grow/shift 操作都绕开了copy的重叠陷阱，而是控制 dst 不与 src 重叠
如何快速判断两个 slice 是否重叠？
Go 没有内置函数判断重叠，但可以用 unsafe 算地址（仅限调试或极端性能场景）。生产代码建议避免依赖重叠——要么明确不重叠，要么用非重叠方式重构逻辑。
立即学习“go语言免费学习笔记（深入）”；
简易判断逻辑（基于 reflect 和 unsafe）：
func overlap(x, y []int) bool {
if len(x) == 0 || len(y) == 0 {
return false
}
x0 := uintptr(unsafe.Pointer(&x[0]))
y0 := uintptr(unsafe.Pointer(&y[0]))
x1 := x0 + uintptr(len(x))*unsafe.Sizeof(x[0])
y1 := y0 + uintptr(len(y))*unsafe.Sizeof(y[0])
return x0 < y1 && y0 < x1
}
- 该函数返回 true 表示内存区间相交，此时调用
copy需严格按地址顺序检查方向 - 注意：对 nil slice 或零长 slice，
&x[0]会 panic，务必先判空 - 绝大多数业务场景应主动避免构造重叠 slice，而不是事后检测
常见报错或意外结果其实和 copy 无关
很多人遇到 “slice 值变了但没预期效果”，实际是误解了 slice header 的引用语义，而非 copy 行为异常。例如：
-
a := []int{1,2,3}; b := a; copy(b, []int{9,9});→a也变成[9 9 3]，这不是copy的错，是b和a共享底层数组 - 用
copy向子 slice 写入时，如果 dst 容量不足但 len 足够，不会 panic，只会截断——这是预期行为，不是 bug - 并发读写同一底层数组的 slice，哪怕没用
copy，也是 data race，跟copy的重叠规则无关
重叠 slice 的坑不在“会不会崩”，而在“结果可预测但反直觉”。最稳妥的做法，是让 dst 和 src 完全不共享底层数组——比如用 make 分配新空间，或用 append 构造独立副本。
