Go append 后底层数组变化的判断方法

判断 Go 的 append 是否换了底层数组，先看这次新增的元素数是否超过当前切片的剩余容量：容量足够时复用原数组，容量不足时为结果切片分配新数组。这里要看的是传给 append 的那个切片的 cap，不是另一个别名的容量，也不是最初 make 时记住的数字。

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

另外要分清“底层数组有没有换”与“数组内容有没有变”：复用时 append 会写入新增元素所在的位置；换数组后，旧别名仍指向原来的存储。下面只用 int 元素讨论这层共享关系，不把元素内部的指针引用也算成独立复制。

先用剩余容量判断复用条件

Go 语言规范的 append 说明给出了容量足够复用、容量不足重新分配的规则。排查时可以先记录三个量：追加前长度、追加前容量、本次新增个数。对已经可用且长度不会溢出的正常追加，可比较 新增个数 > cap(s)-len(s)，避免为了判断而先计算可能溢出的长度和。

这张表是规则推导，不是测量数据。无需记住“容量一定翻倍”或某个固定增长比例；新容量的具体数值不应成为业务正确性的前提。最常见的误判，是看到 len 很小就以为一定不会分配，忘了子切片可能已经限制了 cap。

用两个最小例子看清别名影响

同一个切片赋给另一个变量，并不会复制其中的元素。把 append 的结果保存为新变量，也不意味着它自动拥有独立数组。先看一个容量足够的例子：

package main

import "fmt"

func main() {
    // 旧视图保留两个元素，但底层仍有可供追加的位置。
    base := make([]int, 2, 5)
    base[0], base[1] = 12, 24
    alias := base
    grown := append(base, 36)

    // 复用的情况下，修改重叠位置会被旧别名看到。
    grown[0] = 90
    fmt.Println(alias)
    fmt.Println(grown)

    // 旧别名的长度不自动增长；合法重切片才能看到第三项。
    fmt.Println(alias[:3])
}

按此代码可推导：alias 为 [90 24]，grown 为 [90 24 36]，alias[:3] 为 [90 24 36]。alias 的长度仍是2，直接访问 alias[2] 会越界；“底层有空间”不等于“当前长度允许索引”。这些是语义预期，本文没有把示例作为真实执行记录。

再把容量用满，保持旧别名仍然可见：

package main

import "fmt"

func main() {
    // 长度和容量都是2，新增一个元素无法放进原切片容量。
    base := []int{12, 24}
    alias := base
    grown := append(base, 36)

    // 结果数组独立，改写 int 元素不再改变旧数组。
    grown[0] = 90
    fmt.Println(alias)
    fmt.Println(grown)
}

这里 alias 预期仍为 [12 24]，grown 预期为 [90 24 36]。不能进一步硬编码 grown 的具体 cap；示例所需结论只是旧元素与结果元素不再处于同一个数组。

在第一个例子中，base、alias、grown 是三个切片值；它们通过共享数组关联，长度与容量属于各自的视图。新增位置是数组中的位置，不是 alias 自动多出来的元素。

比较元素地址时先保证对应位置一致

对本文非空的 int 示例，可以保留追加前首元素指针，再与结果首元素地址比较。这样观测的是同一个逻辑起点有没有换存储，而不是变量本身的地址。

package main

import "fmt"

func main() {
    // 取元素地址前确认切片非空；该例显式提供两个 int 元素。
    base := make([]int, 2, 5)
    oldFirst := &base[0]
    grown := append(base, 36)

    // 比较数组元素地址，不比较 &base 与 &grown。
    sameStart := oldFirst == &grown[0]
    fmt.Println(sameStart)
}

此例预期为 true。若把初始化改成长度、容量均为2的切片，并仍追加一个 int，则预期为 false。空切片不能照搬 &s[0]；零大小元素类型也不适合用地址相等推断存储身份。不要为了统一这些特殊情况而把 unsafe 指针塞进普通业务判断。

还要检查是否比较了同一偏移：base[1:] 与 base 起点不同，即使仍共享数组，它们的首元素地址也不同。所以首地址不同并不能普遍证明两个任意切片没有共享底层数组。地址比较在这里是受限的诊断方法，不是通用的切片重叠检测器。

需要隔离时选择限容或显式复制

如果只是禁止接收者的下一次非空追加覆盖原视图后方的位置，可以用完整切片表达式限制容量。若连现有元素的改写也不能影响原数组，就必须显式复制。不要把这两种目标混为一谈。

package main

import "fmt"

func main() {
    base := []int{12, 24, 48}

    // 限容只设置视图边界；已有位置仍与 base 共享。
    limited := base[:2:2]
    limited[0] = 15

    // 非空追加超过 limited 的容量，extended 得到新的数组。
    extended := append(limited, 36)
    extended[0] = 90

    // make 加 copy 明确复制现有 int 元素，立即解除元素存储共享。
    detached := make([]int, len(base))
    copy(detached, base)
    detached[1] = 80

    fmt.Println(base)
    fmt.Println(extended)
    fmt.Println(detached)
}

按代码推导，base 为 [15 24 48]，extended 为 [90 24 36]，detached 为 [15 80 48]。limited[0] 的改写仍影响 base，扩容后的 extended[0] 不影响 base，复制后的 detached[1] 也不影响 base。这三个观察点足以区分限容与复制，不需要打印不稳定的十六进制地址。

Go 官方切片文章解释了切片视图与底层数组的联系。可以把 limited 看成“已有位置可共享、追加空间不可越过”的借用视图，把 detached 看成另一个元素容器。对空切片，make 加 copy 会产生非 nil 的空切片；若业务区分 nil 与空，复制函数应另外约定。

本文第二张图中的 base、limited 与 extended 对应上面的限容例子，detached 对应显式复制。原数组与新数组只是存储边界标签，并不表示不同 goroutine 或执行阶段。

把判断规则落到函数接口与排错清单

调用函数追加元素时，一定使用返回的切片。函数接到的是切片值，参数的长度变化不会自动回写调用者的切片变量；但容量足够时，对共享数组的写入依然可能被其他别名观察到。不能用“函数参数是值传递”推断“元素绝不会改变”。

// addCode 不承诺独占输入数组；调用方必须接收返回值。
func addCode(codes []int, next int) []int {
    return append(codes, next)
}

// addCodeCopy 明确复制 int 元素，避免改写输入元素存储。
// 这里只是浅层元素复制；若元素类型改成指针，需重新约定所有权。
func addCodeCopy(codes []int, next int) []int {
    result := make([]int, len(codes), len(codes)+1)
    copy(result, codes)
    return append(result, next)
}

以上是可放入同一包的函数片段，不是独立 main 程序。第二个函数面向能够分配 len+1 大小的正常输入；极端长度溢出、内存不足等情形不在示例承诺范围内。复制有分配和拷贝成本，不应仅为“保险”在所有调用层重复执行，应该先明确谁可以修改和保留这个切片。

为什么预分配之后反而看到其他视图的数据变了？

预分配提高了复用原数组的可能性，别名共享因此持续存在。先检查谁保留了旧视图，谁正在覆盖重叠位置或旧长度以外、旧容量以内的位置，不能把预分配当成数据隔离方案。

cap 没变能说明两个任意切片共享数组吗？

不能。两个独立 make 的切片可以拥有相同 len 与 cap。容量判断针对的是同一次 append 的输入与新增数量，不是比较任意两个容器的身份。

append 空切片能强制断开共享吗？

不能用没有新增元素的追加来要求分配。需要立即独立保存已有元素时，采用明确的复制方案。若元素本身包含指针、map 或切片，外层复制仍保留内部引用；是否深复制由业务数据模型决定。

排查这类问题时，先画清切片视图的起点、长度与容量，再判断本次追加能否落在原空间中。对外接口则明确返回值和所有权，不依赖某次运行碰巧发生了扩容。