Go append 后修改新切片为什么会影响旧切片

这类现象通常不是 append 把旧切片“改名”了，而是新旧切片仍然共用一块底层数组。容量足够时，append 可以在原数组的后续位置写入；如果新切片又修改了与旧切片重叠的下标，旧切片读到的内容就会一起变化。容量不够时才会分配新数组，所以不能只凭“调用了 append”判断两者已经隔离。

判断关键只有两个：看 cap 是否允许复用底层数组，再看修改的下标是否落在旧切片的可见范围内。需要稳定隔离时，主动 make 加 copy，不要把扩容结果当作副本保证。

先看清 append 返回的切片与底层数组关系

Go 的切片值可以理解为“数组起点、长度、容量”的描述符。切片赋值只复制这个描述符，不会自动复制元素。下面的例子刻意留下容量空间：

base := make([]int, 1, 4) // 中文注释：长度为 1，但底层数组还能容纳 3 个元素
base[0] = 10
old := base
newer := append(old, 20) // 中文注释：容量足够时，追加位置可能仍在原数组
newer[0] = 99            // 中文注释：下标 0 与 old 重叠，所以 old[0] 也会读到 99

这里的 old 长度仍是 1，追加的 20 不会凭空出现在 old[1]；但 old[0] 与 newer[0] 指向同一个元素。若把旧切片扩展到它自己的容量范围，就能看到追加槽位中写入的值。

用 len 和 cap 判断旧切片能看到什么

len(s) 是当前允许索引的元素数量，cap(s) 是从切片起点到底层数组末端的容量。排查互相影响时，可以先把三种边界写在纸上：

因此，看到新切片多了元素并不代表旧切片也变长；看到旧切片的已有元素发生变化，也不代表 append 一定返回了同一个切片值，真正共享的是底层数组中的元素存储。

跨越容量边界并比较两种结果

当追加后的总长度超过原切片容量，运行时需要准备更大的数组并复制旧元素，新切片通常就和旧切片分开了。这个“通常”不应被当作业务层的所有权协议，代码仍应明确谁拥有数据。

src := []string{"a", "b"}
shared := append(src, "c") // 中文注释：是否共享取决于 src 当时的容量

isolated := make([]string, len(src)) // 中文注释：先分配独立数组，建立所有权边界
copy(isolated, src)                  // 中文注释：只复制元素，不再依赖 src 的容量
isolated = append(isolated, "c")
isolated[0] = "changed"             // 中文注释：修改副本，不应改变 src[0]

如果只是想限制一个子切片继续向后覆盖，可以使用三下标切片表达式，例如 part := src[:1:1]，让它的长度和容量都为 1。这样下一次 append(part, x) 更容易触发新数组分配，但它不是通用的深拷贝方案；元素本身若是指针、映射或嵌套切片，仍需按业务需要复制内部对象。

需要隔离时显式复制并核对边界

生产代码里，跨模块返回、缓存长期保存、任务交给另一个 goroutine 前，最好把“共享还是独立”写成清楚的约定。排查时按下面顺序检查：

1. 记录旧切片和新切片的 len/cap，确认追加前是否留有容量。
2. 找出发生变化的下标，判断它是否位于两个切片的重叠范围。
3. 需要独立所有权时使用 make、copy 或项目约定的克隆函数。
4. 若数据跨 goroutine 使用，除了复制边界，还要用同步手段避免并发读写冲突。

相关问题

append 一定会创建新数组吗？

不一定。容量足够时可以复用底层数组，容量不足时才需要扩容。即使当前测试触发了扩容，也不要把这个偶然结果当作接口契约。

为什么 old 看不到 append 新增的元素？

因为 old 的 len 没有改变。新增元素可能已经写进共享数组，但 old 只能访问自己的长度范围；在容量允许时重新切片，才可能看到那部分存储。

copy 是深拷贝吗？

不是。copy 只复制切片元素；如果元素包含指针、map 或嵌套切片，内部引用仍可能共享，需要按对象层级设计复制策略。

如何避免函数修改调用方的切片？

先复制再修改，或在函数契约中明确函数会原地更新输入。不要依赖 append 是否刚好扩容来实现隔离。