append 修改原切片数据的容量边界

在 Go 里，append 看起来只是“给切片加几个元素”，但它真正返回的是一个新的切片头。追加后是否改动了原切片背后的数组，取决于新的长度能不能放进原来的容量：容量足够就可能复用底层数组，容量不足才会分配新的数组。

官方地址：https://pkg.go.dev/builtin#append

所以，判断“append 会不会修改原切片”，不能只看语句表面，而要同时看 len、cap、是否共享底层数组，以及调用方有没有保存返回值。

append 先改了什么：返回值和底层数组是两件事

append(s, value) 至少有两个结果需要分开理解。第一，它返回一个新的切片描述符，里面包含新的长度；第二，它可能把元素写入原切片能够触及的底层数组。原来的变量 s 不会因为调用了 append 就自动变长，因此通常必须把结果重新赋给它。

package main

import "fmt"

func main() {
	base := [4]int{10, 20, 30, 40}
	s := base[:2:4] // 注释：s 的 len 是 2，cap 是 4，仍可扩展到 base 的后两个位置。
	_ = append(s, 99) // 注释：没有接住返回值，s 的长度仍然是 2。

	updated := append(s, 88) // 注释：保存返回值，updated 才能看到追加后的长度。
	fmt.Println(len(s), len(updated))
	fmt.Println(base) // 注释：容量足够时，追加值可能已经写入共享底层数组。
}

这段代码想说明的是“切片长度”和“底层数组内容”不是一回事。s 仍只暴露前两个元素，但 append 可能已经把共享数组中的第三个位置写成了新值。若后续把 s 重新切到容量范围内，就可能看到这个位置。

容量足够时，原切片为什么能看到新数据

当 len(s)+追加数量 时，Go 可以直接在原底层数组的后续位置写入元素，然后返回一个长度更大的切片。此时，原切片和追加结果仍然指向同一块数组，两个切片之间的写入会互相影响它们都能访问到的元素。

package main

import "fmt"

func main() {
	items := make([]string, 2, 4)
	items[0], items[1] = "a", "b"
	view := items[:2:4] // 注释：第三个索引把 cap 明确限制为 4，便于观察共享范围。

	grown := append(view, "c") // 注释：容量足够，grown 与 view 共享底层数组。
	grown[0] = "changed" // 注释：修改共享位置，原切片可见的元素也会变化。
	fmt.Println(items[0], grown[0])
	fmt.Println(view[:3]) // 注释：重新切片后，可以看到追加写入的第三个位置。
}

这里的“修改原切片”更准确地说，是修改了原切片和新切片共享的底层数组。原切片当前长度之外的元素不会凭空出现在它的正常遍历范围里，但同一个数组的其他视图仍可能暴露这些写入。

还要注意，append 不承诺使用某个固定的扩容倍数。业务代码可以依赖“容量不足时返回的新切片不再与旧数组共享”这一语义结果，但不应把运行时具体分配容量当成接口契约。

容量不够时，为什么旧切片又看不到

如果追加后的长度超过当前容量，运行时会分配一块新的底层数组，把原有元素复制过去，再把追加元素写入新数组。此时，返回的新切片和旧切片通常已经分开；但这不改变一个基本要求：仍然要保存 append 的返回值。

package main

import "fmt"

func main() {
	original := make([]int, 2, 2)
	original[0], original[1] = 1, 2

	copyOfView := append(original, 3) // 注释：容量不足，结果会转到新的底层数组。
	copyOfView[0] = 99 // 注释：只修改追加结果，不应把它当成原数组的写入。

	fmt.Println(original[0])
	fmt.Println(copyOfView[0])
}

“通常已经分开”是为了强调工程边界：不要通过比较地址、猜测扩容策略来编写业务逻辑。需要隔离时，应显式表达隔离意图，而不是等待某次容量不足碰巧触发重新分配。

工程代码怎样控制这个边界

如果一个函数把内部缓冲区的切片交给调用方，又不希望调用方的 append 覆盖缓冲区后面的数据，可以使用三索引切片把容量收紧到当前长度：

func exposeReadOnlyWindow(buf []byte) []byte {
	// 注释：第三个索引让返回切片的 cap 等于 len，调用方追加时不能复用 buf 的尾部。
	return buf[:len(buf):len(buf)]
}

func cloneBytes(src []byte) []byte {
	// 注释：需要完全独立的存储时，copy 比猜测 append 是否扩容更直接。
	dst := make([]byte, len(src))
	copy(dst, src)
	return dst
}

三索引切片适合“保留同一份数据但封住可扩展容量”的场景；cloneBytes 适合跨生命周期、跨协程或需要独立修改的场景。前者仍共享已有元素，后者连已有元素也不共享。

常见问题

append 一定会修改原切片吗？ 不一定。它可能复用底层数组，也可能在容量不足时分配新数组；应根据容量和共享关系判断。

只写 append(s, x) 不赋值可以吗？ 语句可以执行，但调用方拿不到新的长度和数组指向，通常等于丢弃了追加结果。

怎样保证传入切片不会被追加影响？ 如果只需封住尾部容量，用 s[:len(s):len(s)]；如果要彻底隔离已有元素，用 make 加 copy。