Go append复用底层数组造成原切片被意外修改的判断方法

Go 里最容易被忽略的切片问题，不是 append 本身，而是两个切片可能指向同一块底层数组。当容量还有余量时，append 会直接写入这块数组；另一个切片如果覆盖了这个位置，就会看到“自己没有修改，却被改了”的结果。

append 为什么会让原切片看到变化

切片值可以理解为指向数组的指针、长度和容量。下面的示例故意让 tail 与 items 共享数组，并保留可增长空间：

package main

import "fmt"

func main() {
	items := make([]string, 2, 4)
	items[0], items[1] = "go", "slice"
	tail := items[:1]

	// tail 仍指向 items 的底层数组，cap(tail) 还有 3。
	tail = append(tail, "alias")
	// append 复用剩余容量，第二个元素会写入 items 的可见范围内。
	fmt.Println(items, tail, len(items), cap(items))
}

这里的关键不是变量名，而是容量关系：tail 从 items 切出来后仍带着后续容量。若追加元素落在另一个切片的长度范围内，原切片就会出现意外变化；若追加超出容量，运行时会分配新数组，之后两个切片才可能分开。

先用 len 和 cap 做一次判断

排查时不要只打印切片内容，建议把切片来源、长度和容量一起记录。下面这张表可以快速区分风险：

函数参数也遵守同一规则：切片头按值传入，但它指向的数组可能共享。函数内部修改已有索引，调用方能直接看到；函数内部 append 后如果发生扩容，调用方只有在接收返回值时才能使用新切片。

需要隔离时的三种处理方式

如果只是把一段切片交给下游，且不希望下游继续沿着容量增长，可以先封住容量：

package main

import "slices"

func appendWithoutSharing(s []int, value int) []int {
	// 三索引切片把 cap 限制为 len，迫使后续 append 需要新数组。
	sealed := s[:len(s):len(s)]
	return append(sealed, value)
}

// snapshot 返回独立的切片快照，调用方可以继续修改原切片。
func snapshot(s []int) []int {
	// Clone 创建新的底层存储，适合保存不会被原切片改写的快照。
	return slices.Clone(s)
}

上面的 snapshot 需要导入标准库 slices。三索引切片只解决“继续 append 时不要复用”的问题，不会阻止已有索引修改；slices.Clone 才会复制元素到新的底层数组，但复制层级仍停留在元素赋值。

工程上可以按这条清单决定方案：

• 只想限制调用方继续扩容：使用 s[:len(s):len(s)]。
• 需要独立的元素序列：使用 slices.Clone(s)，并保留返回值。
• 元素内部还有指针、map 或 slice：为内部对象另写复制逻辑，不能把 Clone 当成深拷贝。

相关问题：哪些边界最容易漏掉

为什么 append 后一定要重新赋值？

因为 append 可能返回指向新数组的切片头。即使这次没有扩容，也应统一写成 s = append(s, value)，避免以后容量变化时丢失结果。

把参数声明成只读切片能避免别名吗？

Go 的切片参数没有内置只读限定。要表达不共享的边界，应在进入函数时 Clone，或在接口约定中明确调用方不能修改。

三索引切片能保护嵌套对象吗？

不能。它只改变容量上限；如果元素本身是指针或引用型对象，仍需针对对象内容设计复制策略。

因此，看到原切片被“意外修改”时，先把 len/cap、切片来源和 append 返回值放在一起看，再决定是容量封口还是复制快照，通常比直接改成全量深拷贝更稳妥。