Go 问答：append 后原 slice 为什么有时会变，有时不会

Go 里最容易让人误判的 slice 问题之一，就是 append 之后原 slice 为什么有时会变，有时又完全不受影响。这个现象不是随机的，关键只看一件事：这次 append 有没有复用同一个底层数组。

摘要

slice 本身不是数组，它更像一个小结构，里面记录了指向底层数组的指针、长度 len 和容量 cap。当 append 后的新长度没有超过容量时，Go 通常会复用原来的底层数组；当容量不够时，才会分配新的底层数组并复制旧数据。

适合人群

适合刚开始写 Go、经常用 append 拼接数据、做切片截取、处理批量列表的同学。本文默认你已经知道 slice 的基本声明和遍历。

目录

• 先看会改动原数组的例子
• slice 的 len 和 cap 到底表示什么
• cap 够用：append 复用底层数组
• cap 不够：append 分配新数组
• 生产代码怎么避免踩坑

先看会改动原数组的例子

下面这段代码里，x 是从 base 截出来的前两个元素。我们对 x 做 append，结果 base 的第三个元素被改掉了。

package main

import "fmt"

func main() {
    base := []int{1, 2, 3, 4}
    x := base[:2]

    y := append(x, 99)

    fmt.Println("base:", base) // [1 2 99 4]
    fmt.Println("x:", x)       // [1 2]
    fmt.Println("y:", y)       // [1 2 99]
}

很多人第一眼会以为 append 只是生成了 y，怎么会影响 base？答案是：x 和 base 指向同一个底层数组，并且 x 的容量还够放下新元素。

slice 的 len 和 cap 到底表示什么

可以把 slice 理解成三部分：

• 指针：指向底层数组的某个位置。
• len：当前 slice 能直接访问的元素个数。
• cap：从起点开始到底层数组末尾，还能容纳多少元素。

base[:2] 的长度是 2，但容量通常不止 2。对于 []int{1, 2, 3, 4} 来说，base[:2] 的容量是 4，所以再追加一个元素时，可以直接写到原底层数组的第 3 个位置。

cap 够用：append 复用底层数组

当 len(x)+追加数量 时，append 可以在同一个底层数组上继续写。新 slice 的 len 增加了，但旧 slice 仍然只看到自己的 len 范围。

这就是为什么 base 被改了，而 x 打印出来仍然是 [1 2]：x 的长度没有变，但它背后的数组已经被 append 写入了新值。

cap 不够：append 分配新数组

如果你希望 append 不影响原来的底层数组，可以让被截出来的 slice 容量刚好等于长度。Go 支持完整切片表达式 a[low:high:max]，其中容量由 max-low 决定。

package main

import "fmt"

func main() {
    base := []int{1, 2, 3, 4}
    x := base[:2:2]

    y := append(x, 99)

    fmt.Println("base:", base) // [1 2 3 4]
    fmt.Println("x:", x)       // [1 2]
    fmt.Println("y:", y)       // [1 2 99]
}

这里 x 的 len 是 2，cap 也是 2。追加一个元素时容量不够，Go 会创建新的底层数组，把旧元素复制过去，再放入新元素。

这时 y 和 base 已经不共享同一个底层数组，所以后续修改 y 不会再影响 base。

生产代码怎么避免踩坑

如果函数只是临时处理数据，允许共享底层数组，直接 append 没问题。但如果你要把 slice 返回给外部、缓存起来、异步处理，最好主动切断共享关系。

方法一：用完整切片表达式限制容量

func takeFirstTwo(base []int) []int {
    return base[:2:2]
}

这样调用方再 append 时，就更容易触发新数组，减少误改原数据的风险。

方法二：显式复制一份

func clonePart(base []int) []int {
    part := base[:2]
    out := make([]int, len(part))
    copy(out, part)
    return out
}

如果你明确不想共享底层数组，复制是最直观的方式。代码多一两行，但边界更清楚。

常见问题

• append 一定会返回新 slice 吗？会返回 slice，但底层数组不一定是新的。
• 原 slice 的 len 会变吗？不会。append 返回的新 slice len 变了，旧 slice 的 len 不会自动改变。
• 为什么 base 会变？因为它和被 append 的 slice 共享底层数组，新元素写进了同一个数组。
• 怎么判断是否共享？看 cap 是否够用，或者在需要隔离时直接复制，不依赖猜测。

总结

Go 的 append 行为可以用一句话记住：cap 够用，复用底层数组；cap 不够，分配新数组。原 slice 有时会被影响，不是因为 append 不稳定，而是因为多个 slice 共享了同一块底层数组。写业务代码时，只要把 len、cap 和共享关系想清楚，这个问题就不神秘了。