Go 切片 append 扩容前后底层数组如何判断

判断一次 append 是否更换底层数组，先比较追加元素数量与 cap(s)-len(s)：放得下就复用原数组，放不下就分配足够大的新数组。要观察某次调用，可保留旧切片，在相同起点、长度非零且元素为 int 的示例里比较 &before[0] 与 &after[0]。不要比较切片变量本身的地址。

官方规范地址：https://go.dev/ref/spec

一个常见疑问是：“给返回的切片改了一个元素，调用方的数据为什么也变了？”下面安排两组可自行运行的小实验，分别保留足够容量和耗尽容量。代码与推导均为原创示例，本文不把预期行为描述为本机实测结果。

前置条件：先看追加量是否超过剩余容量

切片可以理解为对底层数组某一区间的描述，其中包含起点、长度和容量。长度决定当前能索引到的元素，容量决定从该起点能够扩展到哪里。切片赋值复制这份描述，不会复制数组元素。

本轮要追加一个整数，所以原长度为 2、容量为 5 时，无需新数组；原长度为 2、容量为 2 时，需要新数组。结论针对本次调用的输入切片成立，不能只看它最初由哪个 make 创建，也不能把“非 nil”当作容量充足。

初始化：保留旧切片与相同起点

为排除干扰，两组都从长度为 2 的 []int 开始，仅改变容量。before := original 留住旧描述，oldFirst := &before[0] 留住旧首元素地址。append 的返回值放到 after，因而可以同时比较新旧对象。

这个地址比较的前提不能省：两边都必须非空，并且比较同一逻辑位置。对于 original[1:] 这样的偏移子切片，首元素地址不同也可能位于同一个数组里；零大小元素类型也不适合用地址差异证明存储隔离。

编写代码：对照复用和重新分配

package main

import "fmt"

func compare(label string, capacity int) {
    original := make([]int, 2, capacity)
    original[0], original[1] = 14, 28
    before := original
    // 保存相同起点的旧切片；元素类型 int 非零大小，且长度大于零。
    oldFirst := &before[0]
    after := append(original, 42)

    fmt.Printf("%s: len=%d cap=%d -> len=%d cap=%d\n",
        label, len(before), cap(before), len(after), cap(after))
    fmt.Printf("首元素地址相同: %t\n", oldFirst == &after[0])

    // 在受控示例中修改重叠位置，观察旧切片是否跟着变化。
    after[0] = 700
    fmt.Println("旧切片:", before, "新切片:", after)
}

func main() {
    compare("容量足够", 5)
    compare("容量不足", 2)
}

将代码保存为 append_array.go，在安装 Go 的环境中可自行执行：

# 运行这份独立示例，不需要第三方依赖。
go run append_array.go

代码先比较地址，再修改 after 的第一个元素。它没有用 unsafe，也没有把指针转成整数保存。两个切片变量保留在函数内，旧数组不会因为被替换就立即失去引用。

运行检查：地址、长度和元素变化各说明什么

第一组的 before 长度仍为 2，after 长度为 3；它们的首元素地址应相同。after 第一个元素改为 700 后，before 对应元素也应为 700。追加的 42 位于原数组的第三个位置，但 before 的长度没有扩展，不能直接读取 before[2]。

第二组追加前容量耗尽，after 使用新数组，首元素地址应不同。修改 after 第一个元素后，before 第一个元素应仍为 14。这个结论来自两组明确的容量条件；新增容量究竟是多少，不是本文判断数组关系需要依赖的事实。

以下三种观察要分清：len(after) 增加，只证明可见范围变大；&after 是切片变量的地址，不是数组地址；元素值一开始相同，也可能只是扩容时复制了元素。当前受控示例把容量规则、相同位置地址和重叠修改结合起来，才能把现象解释完整。

不要用固定的“翻倍”或某个增长比例作为业务假设。语言规范规定容量不足时分配足够大的数组，并没有要求每次增加后的 cap 等于固定倍数。程序可以观察它，不应依赖某次打印出的容量数值作为所有环境的通则。

扩展实验：限制容量与真正复制

如果只想阻止下游 append 写入原切片的备用容量，可以使用完整切片表达式限制容量。下面片段可放进 main 中，已有 fmt 导入。

base := []int{14, 28, 42, 56}
limited := base[:2:2]
// 限制容量不会复制前两个元素，当前仍与 base 共享它们。
limited[0] = 90
extended := append(limited, 70) // 超过 limited 的容量，得到新数组。
extended[0] = 800
fmt.Println(base[0], limited[0], extended[0])

这段代码按语义推导，base 与 limited 的第一个值都为 90，extended 的第一个值为 800。限制容量隔离的是之后超容量追加的存储，并不让 limited 在追加之前就独立。若调用方立刻修改 limited 的已有元素，base 仍受影响。

要从一开始就隔离整数元素，则明确分配并复制：

source := []int{14, 28}
detached := make([]int, len(source))
copy(detached, source) // 把已有整数复制到另一份存储中。
detached[0] = 901
fmt.Println(source[0], detached[0])

本例复制的是 int，所以两份槽位独立。若元素是指针、map、切片或包含它们的结构体，copy 仍然是元素赋值；即使外层数组已分开，元素内部引用的数据也可能共享，需另按对象结构处理。

清理与常见问题

用完这类实验中的切片无需手动释放。若某个长寿命子切片保留了大数组引用，旧数组可能继续存活；要只保留必要数据，可以像上面的 detached 那样复制到独立的小切片。这里的地址观察仅服务于解释，不是生产中跟踪数组身份的通用工具。

空切片可以比较第一个元素地址吗？不能，长度为零时读取 s[0] 会越界。先用容量条件分析，或另选非空受控输入，不要强行解引用。

append 后为什么必须接收返回值？返回值携带新长度、可能更新的容量和数组引用。函数参数接收的切片描述也是副本，不能期待调用方的长度随参数内部追加自动更新。

容量不同是否一定代表底层数组不同？不是。完整切片表达式可以在同一个数组上限制容量，偏移子切片也会改变可用容量。需要区分“任意两张切片的关系”和“这一次 append 的行为”。

扩容能否作为并发隔离手段？不要这样设计。调用之前仍可能共享输入；对共享元素的并发读写还需同步或事先复制并明确所有权，不能押注某一次追加碰巧扩容。

参考：Go 规范：追加与复制切片、Go 官方切片介绍。