Go 切片 append 通过 Clone 隔离共享数据

我第一次在一个函数里“保护原切片”时，最容易犯的错是只换了变量名：把 items 赋给 work，然后对 work 做 append，就以为原数据已经隔离。实际上，切片只是对底层数组的一段描述，append 是否复用原数组取决于容量。

如果后续逻辑会改写元素，比较清楚的边界是先用 slices.Clone 建立副本，再在副本上追加或排序。这个选择隔离的是切片的底层数组，不是元素内部所有引用。

结论：先判断切片是否可能与调用方共享底层数组；需要独立写入时使用 slices.Clone。Clone 是浅复制，嵌套切片、指针或 map 仍要单独设计所有权。

append 为什么有时改到原切片

Go 语言规范指出，切片与底层数组关联，多个切片可以共享同一段存储。切片的 len 是当前可见元素数量，cap 则描述从切片起点开始还能延伸多远。只复制切片变量，不会复制底层数组。

package main

import "fmt"

func main() {
	base := make([]string, 2, 4) // 预留容量，让派生切片仍可能共享底层数组
	base[0], base[1] = "a", "b"
	view := base[:1] // 只改变可见长度，没有复制元素
	view = append(view, "x") // 容量足够时，写入共享数组的下一个位置

	fmt.Println(base) // base 的第二个元素可能已被改写为 x
	fmt.Println(len(view), cap(view)) // len 是可见数量，cap 影响是否能复用数组
}

这里的关键不是“append 总会修改 base”，而是 view 仍拥有可用容量时，追加元素可能落在原数组的后续位置；当容量不足，运行时会为结果分配新的底层数组。调用方不能把这种分叉当成稳定的隔离策略。

把容量分叉当成架构边界

在我看来，append 的真正风险是所有权不清：一个函数拿到切片后，调用方不知道它会不会修改原数组；被调用方也不应该靠猜容量来保证“不影响输入”。如果函数的职责是生成新集合，最好明确“输入只读、返回独立存储”的契约。

import "slices"

func withExtra(input []string, extra string) []string {
	result := slices.Clone(input) // 先复制底层数组，避免追加复用调用方存储
	return append(result, extra) // 只在副本上扩展结果
}

如果只是读取或临时遍历，可以直接接收输入切片；如果要排序、删除、覆盖元素，或者把结果交给异步任务，建议在边界处显式复制。这样做会增加一次元素复制的成本，但把“谁可以写”从隐含行为变成了代码中可读的约束。

用 slices.Clone 建立写入隔离

slices.Clone 的签名保留输入切片的具体切片类型，元素通过赋值复制。对普通值元素来说，返回结果使用独立的底层数组，后续 append、排序或覆盖不会因为数组共享而改写输入。

package main

import (
	"fmt"
	"slices"
)

func main() {
	input := []string{"go", "slice"}
	work := slices.Clone(input) // 复制元素到独立底层数组
	work = append(work, "clone") // 后续写入只作用于 work 的数组

	fmt.Println(input) // 仍是 [go slice]
	fmt.Println(work) // 是 [go slice clone]
}

这个模式适合“读取输入、构造新结果”的函数，也适合把共享缓存切成一个可修改工作副本。它不等于深复制：若元素本身是指针、切片、map 或包含这些字段的结构体，Clone 只复制外层元素值，内部引用仍可能指向同一对象。

浅复制、nil 与空切片的取舍

官方文档明确说明 Clone 是 shallow clone，并保留输入的 nil 性质。因此需要先区分三个问题：是否要隔离底层数组、是否要递归复制元素、是否要保留 nil 与非 nil 空切片的语义。

type Record struct {
	Tags []string
}

func copyRecords(input []Record) []Record {
	result := slices.Clone(input) // 只复制 Record 外层值，不复制 Tags 底层数组
	if result == nil {
		return nil // 保留调用方用 nil 表示“没有结果”的约定
	}
	return result
}

如果 Record.Tags 也会被修改，就需要为每条记录单独复制 Tags；如果业务只要求外层集合不被 append 影响，Clone 已经足够。至于 nil 切片和长度为零但非 nil 的切片是否要统一，应该由 API 契约决定，不要在复制函数里悄悄改变。

判断清单：什么时候该 Clone

我的经验是：不要把“这次 append 恰好分配了新数组”当成设计保证。只要函数边界允许写入，就用 Clone 或更明确的构造方式表达所有权；如果性能确实敏感，再针对数据规模和调用频率做单独测量，而不是用容量细节猜结果。

相关问题

Clone 会不会把嵌套切片一起复制？

不会。它复制的是外层元素赋值；嵌套切片、指针和 map 里的引用仍可能共享内部数据。需要递归隔离时，要按数据结构逐层复制。

空切片也应该 Clone 吗？

看函数契约。如果只需要一个可追加的独立结果，Clone 可以让意图清楚；如果需要保留 nil 与非 nil 空切片的区别，注意 Clone 会保留输入的 nil 性质。

参考依据：Go 官方 https://pkg.go.dev/slices#Clone 与语言规范 https://go.dev/ref/spec#Appending_and_copying_slices。