Go append 修改了原切片内容怎么判断是否共享数组

Go 的 append 是否复用底层数组，要看追加后的长度能否放进原切片容量：放得下就复用，放不下就分配新数组。若一个短切片来自长切片的前缀，append 可能覆盖长切片仍然可见的尾部元素；这不是 append 回头修改了短切片已有前缀，而是两个视图指向同一块存储。

Go 官方地址：https://go.dev/。排查时记录子切片的起点、len、cap 和追加数量，不要依据扩容倍率或打印值相同来猜共享关系。

先判断追加位置是否仍在原容量内

将切片理解为底层存储引用、长度和容量组成的一个视图。赋值 b := a 或普通重切片只产生新的视图，不自动复制元素。append 返回新的切片值，因此始终接住返回值；返回结果可能仍引用旧数组，也可能已经引用新数组。

判断一次普通追加的直接条件是：新长度是否超过追加前的 cap。这里只讨论正常大小的切片，不把整数溢出或内存分配失败当作普通分支。Go append 规范明确区分复用与分配，但不要求程序依赖某个固定扩容倍率。

用固定容量示例看清覆盖的是哪个元素

下面完整示例显式建立长度为 5 的数组，避免把运行时选出的扩容容量当成语言保证。

package main

import "fmt"

func main() {
    storage := [5]int{11, 22, 33, 44, 55}
    whole := storage[:]
    head := whole[:2] // 长度为 2，但容量仍为 5。

    extended := append(head, 99)
    // 对照重叠位置；两者均非空，因此可以安全取元素地址。
    fmt.Println(whole)
    fmt.Println(head, extended)
    fmt.Println(&whole[2] == &extended[2])

    detached := append(head[:2:2], 77)
    // 容量限制为 2，追加一个元素必然需要新底层数组。
    detached[0] = -1
    fmt.Println(whole)
    fmt.Println(detached)
}

按代码推导：第一次追加后 whole 是 [11 22 99 44 55]，head 仍只显示 [11 22]，extended 是 [11 22 99]，对应索引 2 的地址比较为 true。最后 detached 是 [-1 22 77]，whole 不受 detached 的修改影响。这些是预期语义，不是本文本机运行记录。

如果两切片起点相同且都有元素，比较首元素地址可以帮助观察共同起点；但首元素地址不同不能证明不共享同一数组，例如 whole[1:]。不要为了地址比较索引空切片，也不需要 unsafe 来修复所有权问题。

限制容量只隔离后续追加，不复制已有元素

limited := src[:len(src):len(src)] 令新视图的 cap 等于 len。随后追加至少一个元素时，结果需要新数组；但创建 limited 的那个时刻，已有元素仍然共享。三索引切片规则见 Go 切片表达式规范。

// 此片段放在已有 src 的函数体中，假定 src 非空。
limited := src[:len(src):len(src)]
limited[0] = 80 // 仍修改 src 的同一元素，容量限制不是复制。

result := append(limited, 90)
// 追加后 result 的底层数组已独立，已有元素值被带入新数组。
result[0] = 70

这里的 src[0] 最终仍是 80，而不是 70。追加前发生的修改不会被后来的分配撤销。若只是 append(limited, empty...) 且 empty 没有元素，也不能靠这次调用制造隔离。

需要完全隔离元素存储时先复制

如果调用者要求函数不能改动输入的元素，也不能借其剩余容量覆盖尾部，就先为结果分配元素存储，再 copy。

// CopyAppendInt 返回独立的整数元素存储；nil 输入也可以追加。
func CopyAppendInt(src []int, value int) []int {
    copied := make([]int, len(src), len(src)+1)
    copy(copied, src)
    return append(copied, value)
}

copied 是复制视图，其独立数组与原数组分离，源切片 src 的已有整数不会因修改返回切片而改变。make 预留一个追加位置只是此函数的分配选择，不是通用性能承诺。copy 必须有足够长的目标切片；只 make 长度 0、容量足够的目标再 copy，并不会复制出预期元素。

Go 官方切片介绍解释了共享存储与复制的区别。若元素含指针、map 或 slice，copy 复制的是元素值，不会递归复制它们引用的对象；本例选择 int，因而不引入深层别名。

把共享约定写进函数接口

接口文档不能只说“返回一个新切片”，因为“新切片值”不等于“新数组”。应明确：能否修改输入区间、能否占用输入的剩余容量、返回值是否共享元素存储。需要隔离就复制；只防止后续追加覆盖尾部，可以限制传入视图的容量，但仍不能允许它改写已有索引。

回归示例应至少保留两种输入：len 小于 cap 的子切片，以及 len 等于 cap 的切片。用原始长视图检查尾部，用返回值检查新长度；不能只检查短视图，因为覆盖可能发生在它长度之外。排查结束的依据是所有权约定被兑现，而不是某次 append 恰好扩容。

两切片内容一样就表示共享吗？

不表示。复制后的元素也可以相同；要结合构造方式和重叠存储位置判断。

函数参数按值传递为什么仍能改原内容？

传递的是切片视图的值，元素存储不随参数自动复制。函数中的 append 可能改共享数组，但不会自动更新调用者变量里的长度。

每次都让 append 扩容可以当隔离方案吗？

可以通过容量限制让非空追加分配新数组，但它不隔离追加前的元素访问。对不允许修改输入的 API，显式复制的约定更直接。