Go slice 传入函数后内容为何被改掉：共享底层数组与容量边界

线上批量处理一组订单时，调用方明明只把一个 slice 传给了格式化函数，返回后原切片却多出了一段临时数据。这个现象通常不是“Go 把参数偷偷改了”，而是函数拿到的 slice header 仍然指向同一块底层数组；只要容量还够，函数里的 append 就可能复用这块数组。

函数参数为什么会和调用方共享数据

slice 不是数组本身，而是一个小型描述符，包含指向底层数组的指针、当前长度 len 和可用容量 cap。把 slice 作为参数传入函数时，这三个值会被复制，但指针指向的数组不会跟着复制。

package main

import "fmt"

func rewrite(items []string) {
	items[0] = "已处理"
}

func main() {
	items := []string{"待处理", "待处理"}
	rewrite(items)
	fmt.Println(items) // [已处理 待处理]
}

这里没有发生任何特殊的引用传递：items 和 rewrite 里的参数是两个 slice header，但它们的第一个元素来自同一底层数组。函数只要改的是当前长度范围内的元素，调用方就能看见结果。

append 为什么有时改原数据，有时却不改

append 的关键不是“在函数里调用”，而是当前 slice 的容量是否足够。下面这个例子给切片预留了容量 4，函数追加一个元素时无需申请新数组。

func addTemp(items []string) {
	items = append(items, "临时")
}

func main() {
	items := make([]string, 2, 4)
	items[0], items[1] = "A", "B"
	addTemp(items)
	fmt.Println(items, len(items), cap(items)) // [A B] 2 4
	fmt.Println(items[:3])                    // [A B 临时]
}

调用方的长度仍然是 2，所以直接打印 items 看不到“临时”；但同一底层数组的第三个位置已经被写入。只要调用方把 slice 扩到长度 3，就能读到它。

如果容量不够，append 通常会分配一块新数组，函数参数改为指向新数组，调用方仍指向旧数组。不过不要把“通常”当成业务契约，代码应该明确返回追加后的 slice，因为只有接住返回值才能可靠获得新长度和新地址。

三种方式分别解决共享、追加和返回值问题

需要完整副本时先 Clone

如果函数会排序、过滤、覆盖元素，而调用方必须保留原顺序，先复制一份最清楚。Go 1.21 及更新版本可以使用 slices.Clone；兼容更早版本则可以用 append([]T(nil), items...)。

func sortedCopy(items []int) []int {
	copyItems := append([]int(nil), items...)
	sort.Ints(copyItems)
	return copyItems
}

复制只隔离 slice 这一层。如果元素本身是指针、map 或包含引用字段的结构体，还要继续判断元素内部是否需要深拷贝。

只允许在现有长度内修改时限制容量

可以用三索引切片把容量收紧到长度：limited := items[:len(items):len(items)]。这样函数即使调用 append(limited, x)，也会因为容量不足而走新数组，避免覆盖调用方后面的预留空间。

这个技巧只限制追加，不会阻止函数执行 limited[0] = x。如果连已有元素也不能改，仍需要复制。

函数需要追加结果时返回新 slice

func withDefault(items []string) []string {
	if len(items) == 0 {
		return []string{"默认值"}
	}
	return append(items, "尾部标记")
}

items = withDefault(items)

把新 slice 返回给调用方，能同时处理两种情况：容量足够时返回同一底层数组但长度变长，容量不足时返回新数组。调用方不再依赖猜测。

一个小测试就能锁定别名边界

排查这类问题时，不要只打印 slice。把长度、容量和扩展后的内容一起断言，才能区分“长度没变”和“底层数据没写入”。

func TestAppendDoesNotTouchTail(t *testing.T) {
	input := []string{"A", "B"}
	limited := input[:len(input):len(input)]
	got := append(limited, "C")

	if len(input) != 2 || input[0] != "A" || input[1] != "B" {
		t.Fatalf("input changed: %#v", input)
	}
	if !reflect.DeepEqual(got, []string{"A", "B", "C"}) {
		t.Fatalf("got %#v", got)
	}
}

还可以在测试中打印 %p 查看首元素地址，但地址只适合辅助定位，不应写成稳定断言。更有价值的是围绕“函数是否允许修改输入”“是否必须保留原顺序”“追加结果是否必须接收”写行为测试。

常见误区与选择清单

相关问题

把 slice 改成数组参数能避免这个问题吗？

固定长度数组按值传递时会复制全部元素，但它改变了函数签名和长度模型。大多数需要可变长度数据的接口，应该显式复制 slice，而不是为了规避别名强行改成数组。

为什么 append 的返回值不能忽略？

追加可能改变长度，也可能因为扩容换底层数组。忽略返回值后，函数内部的结果不一定回到调用方，且调用方无法知道新长度。

并发读取 slice 时只要不 append 就安全吗？

不一定。只要一个 goroutine 修改元素，另一个 goroutine 同时读取，就可能产生数据竞争；应通过同步机制或不可变副本建立清晰的读写边界。

把 slice 边界写进接口

遇到“函数调用后原数据变了”，先看参数是否共享底层数组，再同时检查 len 和 cap。需要隔离就复制，需要限制追加就收紧容量，需要得到追加结果就返回 slice。把这三个意图写进函数名、注释和测试，后续维护者就不必靠猜。