在 Go 语言中，切片追加是最常用的操作之一。常见写法是 s = append(s, v)，其中重新赋值这一步经常被初学者忽略。直接写 append(s, v) 不会导致编译错误，但运行结果往往与预期不符。要理解为什么必须重新赋值，不能只看表面语法，而需要回到切片的底层表示。Go 的切片不是数组本身，而是一个描述数组片段的结构体，它包含三个字段：指向底层数组的指针、长度和容量。只要抓住这个模型，append 的行为就非常清晰。
切片底层结构与 append 的返回值
切片在运行时由类似 SliceHeader 的结构表示，核心字段是 Data、Len 和 Cap。Data 指向一块连续内存的起始地址，Len 表示当前可以访问的元素个数，Cap 表示从 Data 开始到底层数组末尾还能容纳多少个元素。例如 make([]int, 2, 5) 创建的切片长度是 2，容量是 5，底层数组实际上有 5 个位置可用，但只允许通过下标访问前两个元素。
append 函数定义类似 func append(slice []Type, elems ...Type) []Type。它接收一个切片，返回一个新切片。注意，Go 所有函数参数都是值传递，切片也不例外。调用 append 时，传入的是切片头的副本，也就是 Data、Len、Cap 三个字段的拷贝。函数内部对这个副本所做的 len 修改，不会影响调用方原来的切片头。因此 append 必须通过返回值把更新后的切片头交还给调用方。
如果容量足够，append 会把新元素写入底层数组的第 Len 个位置，然后把副本的 Len 加 1 并返回。原始切片的 Len 不变，因此无法通过原变量访问刚追加的元素。但如果通过扩展切片表达式 s[:cap(s)] 去查看底层数组，有时能看到数据已经写入，这正是很多困惑的来源：数据明明在底层数组里，为什么切片看不到？因为访问范围由 Len 决定，而不由实际写入位置决定。
容量足够与容量不足的两种场景
容量足够时，append 不会分配新数组。下面的示例中，切片长度初始为 2，容量为 5。直接调用 append 后，底层数组第 3 个位置被写入 30，但原切片的长度仍然是 2。
package main
import "fmt"
func main() {
s := make([]int, 2, 5)
s[0] = 10
s[1] = 20
fmt.Println("追加前:", s, "len =", len(s), "cap =", cap(s))
_ = append(s, 30)
fmt.Println("未重新赋值:", s, "len =", len(s), "cap =", cap(s))
// 扩展访问底层数组可以看到 30
fmt.Println("扩展到底层容量:", s[:cap(s)])
}
输出中，未重新赋值的 s 仍然是 [10 20]，长度还是 2，但 s[:cap(s)] 显示为 [10 20 30 0 0]。这说明底层数组确实被修改，但原切片头没有同步。只有执行 s = append(s, 30)，s 的长度才会变为 3，正常访问 s[2] 才能得到 30。
容量不足时，append 会创建一个新的底层数组，新数组容量通常是旧容量的两倍左右，然后把旧元素和新元素拷贝过去，并返回指向新数组的切片头。此时如果不接收返回值，原切片仍然指向旧数组，新数组中的数据与原变量完全脱离关系。下面的代码展示了扩容场景：
package main
import "fmt"
func main() {
old := make([]int, 0, 2)
old = append(old, 1, 2)
fmt.Println("old 初始:", old, "len =", len(old), "cap =", cap(old))
newSlice := append(old, 3)
fmt.Println("old 未变:", old, "len =", len(old), "cap =", cap(old))
fmt.Println("newSlice:", newSlice, "len =", len(newSlice), "cap =", cap(newSlice))
}
运行时 old 的容量为 2，追加第三个元素必然触发扩容。newSlice 的长度变为 3，容量通常变为 4，而 old 仍然保持长度 2、容量 2。若调用方丢弃 newSlice，那么元素 3 只存在于新数组中，原变量 old 完全无法访问到它。因此，不管是容量足够还是不足，丢弃 append 返回值都会造成原切片头信息过期。
函数内 append 的常见陷阱
把切片传入函数并在函数内部追加，是另一个容易出错的地方。函数参数是切片头的副本，因此函数内即使写了 s = append(s, v)，也只改变了副本，外部的切片变量不会改变。若函数返回新切片，并在调用处接收，则没有问题。以下示例说明这一点：
package main
import "fmt"
func addOne(s []int) {
s = append(s, 100)
fmt.Println("函数内部:", s)
}
func addOneReturn(s []int) []int {
return append(s, 100)
}
func main() {
nums := make([]int, 0, 4)
addOne(nums)
fmt.Println("addOne 后外部:", nums, "len =", len(nums))
nums = addOneReturn(nums)
fmt.Println("addOneReturn 后外部:", nums, "len =", len(nums))
}
运行结果是，addOne 内部打印出 [100]，但外部 nums 仍然是空切片，长度为 0。原因就是函数接收的是切片头副本，副本里的 len 被更新了，但外部的 len 没有变化。改成 addOneReturn 后，函数把更新后的切片头作为返回值，外部重新赋值，切片就能正常包含新元素。这个陷阱在封装数据操作函数时非常常见。
如果希望在函数内部修改外部切片，除了返回新切片外，还可以传入指向切片的指针，例如 func addOne(s *[]int)，然后执行 *s = append(*s, 100)。不过这种方式一般不如返回新切片直观，在实际项目中更常见的做法是始终接收返回的切片。
最佳实践与性能考量
为了避免 append 带来的隐蔽错误，建议遵守一条规则：只要调用 append，就一定要把返回值赋回原变量。即使当前容量足够，也不能假设底层数组会一直原地修改，因为未来的代码可能改变初始容量或数据处理路径。写成 s = append(s, v) 不仅语义清晰，还能同时应对扩容和不扩容两种情况。
在循环中追加时，如果能够预估元素数量，建议使用 make([]T, 0, capacity) 提前分配足够容量。这样可以减少扩容次数，避免反复分配内存和拷贝元素。例如处理 10000 条记录时，可以先 records := make([]Record, 0, 10000)，然后循环 append。若不分配初始容量，append 在容量不足时会按一定策略扩展，虽然平均复杂度仍然是分摊 O(1)，但频繁扩容会增加 GC 压力。
另一个需要注意的点是多切片共享底层数组。对切片截取得到的子切片，可能与原切片共享同一底层数组。此时对子切片执行 append，如果容量足够，会直接修改底层数组，影响原切片对应位置。如果不希望共享底层数组，可以在追加前使用 copy 创建独立副本。理解 append 的返回值机制，也有助于判断哪些操作会写回共享数组，哪些操作会因扩容而脱离共享关系。
总结来说，Go 语言要求重新赋值并不是多此一举，而是切片值语义的必然结果。切片头只是底层数组的一个窗口，append 改变了窗口边界，甚至可能打开一个全新的窗口，因此必须接收新的窗口描述符。掌握这一点后，不仅能正确追加元素，也能更深入地理解 Go 内存布局和值传递模型。