Go slices.Clone 和直接赋值怎样选择

我在整理配置快照时遇到过一个很隐蔽的现象：把一个切片赋给另一个变量后，调用方修改“副本”，原始配置也跟着变了。原因不是 Go 把变量弄混了，而是直接赋值只复制切片头，两个变量仍然指向同一块底层数组。

官方资料：https://pkg.go.dev/slices#Clone

选择可以先记成一句话：只想换一个切片视图就直接赋值；需要独立的底层数组就用 slices.Clone；需要兼容较老 Go 版本时可用 append([]T(nil), src...)，但三种写法都不是递归深拷贝。

直接赋值为什么会共享修改

切片可以理解为指向数组的一小段描述信息，包含数据指针、长度和容量。赋值时复制的是这三个字段，不会把元素逐个搬到新数组里。因此下面的 alias 和 source 是两个切片头，却观察着同一个数据区。

package main

import "fmt"

func main() {
	// 直接赋值只复制切片头，alias 与 source 共享底层数组。
	source := []int{10, 20, 30}
	alias := source

	// 修改 alias 的元素会反映到 source，这是共享视图的结果。
	alias[0] = 99
	fmt.Println(source) // [99 20 30]
}

这种写法本身没有错。函数只读参数、多个组件共同查看一份稳定数据时，共享视图可以避免一次复制。真正危险的是把它当成“备份”后，再让其中一方承担写入责任。

需要独立副本时用 slices.Clone

slices.Clone 的意图更清楚：把源切片的元素复制到一块新的底层数组，再返回同长度的切片。它是泛型函数，对命名切片类型也能保留类型信息，适合作为配置快照、请求参数副本或可变工作缓冲区。

package main

import (
	"fmt"
	"slices"
)

type Ports []int

func main() {
	// Clone 复制元素并建立新的底层数组，命名切片类型仍然是 Ports。
	source := Ports{8080, 8081}
	working := slices.Clone(source)
	working[0] = 9000

	// working 的修改不会污染 source，适合交给后续逻辑自由改写。
	fmt.Println(source)  // [8080 8081]
	fmt.Println(working) // [9000 8081]
}

这里的“独立”只针对切片元素所在的数组。如果元素是指针、切片、映射或包含这些字段的结构体，Clone 只复制元素值，元素内部引用仍可能指向同一对象。本文讨论的是切片头和底层数组，不把它扩展成通用深拷贝方案。

append 复制什么时候仍然有价值

在没有 slices.Clone 的旧 Go 版本中，常见兼容写法是用空切片承接展开元素。它同样会创建独立数组，但表达力和 nil 行为需要单独看清。

// cloneCompat 用标准库基础能力复制元素，便于兼容较老 Go 版本。
func cloneCompat[T any](src []T) []T {
	// 以 nil 作为起点，空源切片会得到 nil；需要保留非 nil 空切片时要另行处理。
	return append([]T(nil), src...)
}

如果项目已经使用支持 slices.Clone 的 Go 版本，优先采用名称直接表达意图的写法。append 方案更像底层技巧，还容易被改成 append(src[:0:0], src...) 等依赖容量细节的变体，阅读成本更高。

nil、空切片和浅复制边界

slices.Clone(nil) 会保留 nil 语义；对非 nil 的空切片，Clone 会返回非 nil 的空切片。这个区别在 JSON 编码、接口返回或需要区分“未设置”和“已设置但为空”的场景中可能有意义。

package main

import (
	"fmt"
	"slices"
)

func main() {
	// 分别保留 nil 与非 nil 空切片，观察两种状态的语义差异。
	var nilSource []string
	emptySource := make([]string, 0)

	nilCopy := slices.Clone(nilSource)
	emptyCopy := slices.Clone(emptySource)
	fmt.Println(nilCopy == nil)   // true
	fmt.Println(emptyCopy == nil) // false
}

如果切片元素是 *Config 或 []byte，Clone 不会继续复制每个指针指向的对象或每个嵌套切片。此时要不要深复制，取决于元素模型和写入责任，需要为具体类型设计复制函数，不能只换一个 API 名称。

按读写责任选择最终写法

可以把选择压缩为四个判断：

在并发代码中尤其要先明确所有权：如果一个 goroutine 仍会修改原切片，另一个 goroutine 只读它，直接赋值并不会自动提供隔离；需要的是不可变约定、同步保护，或在交接边界用 Clone 建立独立副本。

常见问题

slices.Clone 会复制切片的容量吗？

调用方应关注它返回的是独立底层数组和相同长度，而不是把源切片的可写容量当作契约。需要控制容量时，应在自己的数据结构边界上明确分配策略。

直接赋值后再 append 一定会影响原切片吗？

不一定。若容量足够，append 可能继续写共享数组；若需要扩容，也可能得到新的数组。不要用一次运行结果推断所有路径，是否共享应由所有权设计决定。

Clone 能解决嵌套结构的深复制吗？

不能。它复制的是切片元素本身；元素里面的指针、映射、切片等引用仍要由业务类型提供明确的复制策略。

最终判断并不复杂：把切片当作只读视图时直接赋值，把它当作可变工作副本时使用 slices.Clone，旧版本再选择 append 兼容写法；只要元素内部还有引用，就把深复制单独当成类型设计问题处理。