Go 切片传给函数后 append 为什么调用方长度没变？返回值该怎么接

写了个批量收集标签的小函数，调试时总碰到调用侧只返回两个元素的怪事：函数内部明明已经 append 了，日志打印也没报错。这不是Go无故丢数据，本质是函数拿到的是切片头的副本，新的长度值只更新到了这份局部副本上，外层原变量完全没同步到这个变化。

只要函数需要让调用方看到新增元素，就把 append 的结果返回并由调用方重新赋值；底层数组是否复用，不会替调用方更新原变量的 len。

先用最小例子看清：元素进去了，长度却没回来

下面的 addBlue 在自己的局部变量上得到了三个元素，main 里的 tags 仍然只有两个。这正是很多接口组装、分页汇总和批量读取代码里最常见的误判点。

package main

import "fmt"

func addBlue(tags []string) {
	tags = append(tags, "blue")
	fmt.Println("inside:", len(tags), tags)
}

func main() {
	tags := make([]string, 2, 4)
	tags[0], tags[1] = "red", "green"
	addBlue(tags)
	fmt.Println("caller:", len(tags), tags)
}

inside: 3 [red green blue]
caller: 2 [red green]

tags 不是一个“会自动变长的数组变量”。它携带了数组引用、len 和 cap 三项信息。传入 addBlue 后，局部参数拥有自己的 len 字段；append 增长的是局部字段，外层变量并不知道这个新值。

接口需要新增元素时，返回新切片是最小且清楚的写法

普通业务函数更适合把新切片作为返回值交给调用处接收。调用点多写一次赋值，换来的是数据流一眼可见：谁扩容、谁拥有更新后的长度，没有隐藏的暗箱状态。

func addBlue(tags []string) []string {
	return append(tags, "blue")
}

func main() {
	tags := []string{"red", "green"}
	tags = addBlue(tags)
	fmt.Println(len(tags), tags) // 3 [red green blue]
}

这里无须猜测是否发生重新分配。容量不够时，append 会准备更大的底层数组；容量够时，它可能沿用原数组。两种情况返回值都代表正确的新切片，所以调用方都应接住它。

容量够时最容易踩的坑：第三个元素并非完全不可见

把容量设为 4 后，局部 append 通常直接写进同一块底层数组。外层 len 还是 2，但如果有人随后把它重新切到长度 3，就可能读到函数写入的值。这不是“调用方已经更新”，反而说明共享存储让错误变得更隐蔽。

func addBlue(tags []string) {
	tags = append(tags, "blue")
}

func main() {
	tags := make([]string, 2, 4)
	tags[0], tags[1] = "red", "green"
	addBlue(tags)

	fmt.Println(tags)    // [red green]
	fmt.Println(tags[:3]) // [red green blue]
}

这段代码只用于解释共享数组逻辑，不建议把 tags[:3] 当成补救方式。调用方不知道函数究竟追加了几个元素，也不知道某次改动后容量是否还足够；一旦扩容发生，隐藏的第三个元素又会消失在另一块数组里。

三种写法分别适合什么边界

指针写法并非不能用，只是它把“函数会改变调用方变量”变成了接口契约，适合累积器或需要就地填充的场景。若采用它，函数名可以写得直白些，例如 appendTagTo，并在调用点明确传 &tags。

func appendTagTo(dst *[]string, tag string) {
	*dst = append(*dst, tag)
}

func main() {
	tags := []string{"red"}
	appendTagTo(&tags, "blue")
	fmt.Println(tags) // [red blue]
}

写完后做两个小检查，能挡住大多数回归

第一，测试返回值的长度和元素，而不是只检查函数内部日志。第二，分别用容量刚好够与容量不足的输入跑一遍；前者验证共享数组时是否仍正确接值，后者验证重新分配时是否仍保留新元素。

func TestAddBlue(t *testing.T) {
	for _, tags := range [][]string{
		make([]string, 2, 4),
		[]string{"red", "green"},
	} {
		tags[0], tags[1] = "red", "green"
		got := addBlue(tags)
		if len(got) != 3 || got[2] != "blue" {
			t.Fatalf("got %v", got)
		}
	}
}

这里别急着盯着扩容次数。业务接口先把返回值契约写对，性能判断再交给真实数据量和基准测试；预估元素数量时，可以在创建切片时给出合理容量，减少不必要的分配。

延伸问答

切片传给函数后，修改 tags[0] 为什么外层能看到？

这是对共享底层数组中的既有位置写值，外层和内层仍指向同一元素；它没有改变外层切片头里的长度。

能不能不接 append 的返回值？

可以写，但新增后的切片值会被丢弃。除非你只是刻意触发副作用且完全不使用结果，否则不应这样写。

预分配容量能否解决长度不变？

不能。预分配只可能减少重新分配；函数参数仍是切片头的副本，长度仍需通过返回值或指针同步。

什么时候需要深拷贝切片？

当你不希望后续追加或元素修改影响原数据时，先创建新切片并用 copy 复制。对嵌套引用类型，还要继续处理内部引用的隔离。

记住这一条就够了

Go 的切片很轻量，但它的长度是切片值的一部分。函数内的 append 产生了新切片，就把它返回；调用方负责接住。这样无论底层数组是否复用，代码的含义和测试结果都会保持稳定。