Go slice append 为什么会修改调用方的底层数组

append 是否会修改调用方，关键不在“切片是值传递”这句话，而在两个切片值是否仍然指向同一个底层数组，以及追加时是否还有足够的 cap。容量足够时，append 可以直接把新元素写进共享数组；容量不足时，它通常会换一块更大的数组。无论哪种情况，调用方都应该接住 append 的返回值。

官方资料：https://go.dev/blog/slices-intro

先区分切片头与底层数组

Go 的 slice 不是数组本身，而是一个指向数组片段的描述符。可以把它理解为“数据起点、可见长度、可使用容量”三部分信息。把一个 slice 传给函数时，描述符会被复制，但它记录的底层数组地址仍可能相同，所以“参数按值传递”并不等于“元素完全隔离”。

package main

import "fmt"

func addMarker(s []int) {
	// 参数 s 是新的切片头，但可能仍指向调用方的底层数组。
	s = append(s, 99)
	// 追加后的切片头只在函数内部生效，调用方的 len 不会自动改变。
}

func main() {
	base := make([]int, 1, 2)
	base[0] = 7
	addMarker(base)
	// 结果示意：base 的长度仍为 1，但容量范围内的下一个槽位可能已写入 99。
	fmt.Println(base, len(base), cap(base))
}

这里最容易混淆的是两个结果同时成立：调用方的 len(base) 仍然是 1，但函数里的 append 可能已经把 99 写入同一块数组的下一个位置。调用方如果随后把切片扩展到容量范围，就可能看到这个值。

用 len 和 cap 判断复用条件

判断是否可能改写调用方，先看追加后的目标长度，再和原切片的容量比较。若追加后仍不超过 cap(s)，运行时可以沿用原数组；若超过容量，就需要分配新数组并复制旧元素。代码层面不应该依赖某次扩容的具体倍数，只需要围绕“是否仍在容量范围内”做边界判断。

package main

import "fmt"

func main() {
	// 预留容量 4，让前两次追加存在复用底层数组的空间。
	items := make([]string, 1, 4)
	items[0] = "go"
	view := items[:1]

	// 追加后长度为 2，仍不超过 cap(view)，可能复用 items 的底层数组。
	view = append(view, "slice")
	// 输出只用于说明观察维度：要关注 len、cap 和两个视图是否共享。
	fmt.Println(view, len(view), cap(view), items[1])

	// 三下标切片把 cap 限制为 len，后续追加不会借用 items 的尾部空间。
	isolated := items[:len(items):len(items)]
	isolated = append(isolated, "copy-on-grow")
	fmt.Println(isolated, items)
}

三下标切片的形式是 s[low:high:max]。把 max 设置为当前长度后，得到的新视图仍然看到原元素，但可追加容量被限制住；下一次 append 需要新的数组。它适合表达“这个视图不能偷偷改写原切片尾部”的意图。

把 append 的返回值传回调用方

即使暂时不关心底层数组，忽略返回值也会丢失追加后的长度，甚至丢失扩容后新的数组地址。函数如果负责追加，应明确返回新的 slice；调用方用 s = appendItem(s, value) 接住它。

package main

import "fmt"

func addName(names []string, name string) []string {
	// 返回新切片头，兼容“原数组复用”和“扩容换数组”两种情况。
	return append(names, name)
}

func main() {
	names := []string{"Ada"}
	// 调用方接住返回值，才能获得追加后的长度和最新底层数组。
	names = addName(names, "Grace")
	fmt.Println(names)
}

这也是审查代码时最稳定的判断方式：不要猜 append 是否扩容，而是把它的返回值当成唯一可信的后续入口。原来的 slice 变量仍可被其他代码持有，因此如果不同视图之间必须互不影响，就要在接口边界明确复制或限制容量。

共享、隔离和复制怎么选

如果只是想隔离切片自身的追加，三下标切片通常足够；如果要隔离元素内容和原数组的生命周期，则应复制。尤其是从大字节数组截取一小段长期保存时，复制还能避免小切片继续持有整块大数组。

排查 append 意外改写的清单

1. 记录追加前的 len、cap 和追加数量，先判断目标长度是否超过容量。
2. 检查是否存在 base[:n]、base[n:] 或多个变量指向同一底层数组。
3. 确认函数是否返回并接住了 append 的结果，而不是只在局部变量中重新赋值。
4. 需要隔离时，明确选择三下标切片还是深层复制，不要把二者当成同一种保证。
5. 异步或跨层传递前，确认原拥有者不会继续写入共享数组。

一句话总结：append 修改调用方可见数据，是因为多个 slice 共享底层数组且容量允许原地追加；它不代表调用方的切片长度会自动改变。理解 len、cap 和返回值三者的分工，就能把这个看似偶发的问题变成可判断的边界。

相关问题

append 一定会分配新数组吗？

不一定。追加后的长度仍在容量范围内时可以复用原数组；超过容量时才需要扩展存储。业务代码应使用返回值，不要依赖具体扩容策略。

为什么函数里 append 了，调用方 len 还是没变？

函数参数复制了 slice header。函数内的新长度只属于新的 header；如果函数没有返回新切片，调用方原来的 header 不会自动更新，但共享数组中的位置仍可能被写入。

三下标切片能完全避免数据共享吗？

不能。它只把可追加容量限制到指定上限，已有元素仍与原数组共享。需要完全独立的数据时，应复制元素；元素内部若含指针，还要评估更深层的共享。