Go append 到容量足够的子切片为什么改了原数据

我第一次遇到这个问题，是把一段请求数据切成两部分分别处理。子切片 append 之后，原切片尾部竟然变了。代码看起来没有给原切片重新赋值，真正改变结果的却是同一个底层数组被复用了。

判断关键不在“是不是子切片”，而在 append 之后的长度是否还没有超过它的容量。容量足够时，Go 会直接写入共享数组；要把这块存储当成只读输入，就要收紧 cap 或先复制。

普通的二索引切片可能保留原数组尾部容量，append 会把新元素写进那块共享空间。用三索引切片把 cap 限制到 len，或创建副本，才能明确隔离修改。

先看清：子切片和原切片共享哪块存储

切片不是数组本身，而是指向数组一段区域的描述值。下面的 part 从 data 的开头切出两个元素，但它的容量仍然延伸到原数组末尾：

data := []int{10, 20, 30, 40}
part := data[:2] // 子切片有 2 个可见元素，但 cap 仍可能是 4
part = append(part, 99) // 容量足够，新增元素写入共享数组

fmt.Println(data) // [10 20 99 40]
fmt.Println(part) // [10 20 99]

这里不是 append “回头修改”了 data，而是 data 与 part 都看着同一个数组。part 原本看不见索引 2，但 append 把长度扩展到 3 后，索引 2 就被写入了。

真正触发改写的是 append 的容量判断

Go 规范把判断说得很直接：如果容量不够，append 会分配能容纳旧元素和新增元素的新底层数组；否则复用原底层数组。可以用下面这张速查表定位现象：

所以排障时先打印 len(part) 和 cap(part)。如果新增元素数量不超过 cap(part)-len(part)，就要把原切片尾部当成潜在的写入目标。即使这次恰好触发扩容，也不要把“没有改到原数据”当成接口保证，因为容量变化会改变结果。

data := []int{10, 20, 30, 40}
part := data[:2:2] // 第三个索引把 cap 收紧到 2
part = append(part, 99) // cap 不够，得到新的底层数组

fmt.Println(data) // [10 20 30 40]
fmt.Println(part) // [10 20 99]

用三索引切片收紧增长边界

三索引表达式 low:high:max 的第三个索引控制容量。对外传递一个只允许读取当前范围、又不希望调用方占用尾部空间的切片时，可以写成：

func window(input []byte) []byte {
    // 限制返回视图的 cap，避免调用方 append 覆盖 input 的尾部。
    return input[:len(input):len(input)]
}

source := []byte{'a', 'b', 'c', 'd'}
view := window(source)
view = append(view, 'x') // 需要新数组，不写 source 的尾部

这是一种轻量的边界控制，不等于深度复制。view 在原长度范围内仍与 source 共享元素；如果调用方会修改已有位置，或者数据要跨 goroutine、缓存层或长期持有，就应该建立副本。

跨函数传递时，我会保留这张检查清单

• 先问所有权：这个参数是借用视图，还是函数可以修改的工作区？
• 再看 cap：普通切片是否把不该暴露的尾部空间一并带出去了？
• 需要防 append 覆盖时，返回 s[:len(s):len(s)]；需要防元素修改时，使用 copy 建立独立存储。
• 函数内部 append 后要接住返回值；扩容后新的切片头可能已经指向另一块数组。
• 多个 goroutine 共享同一底层数组时，别把“切片值传了一份”误认为数据已经隔离，写入仍需要明确同步或复制。

func cloneBytes(src []byte) []byte {
    // copy 到独立切片，避免后续修改回写调用方的底层数组。
    dst := make([]byte, len(src))
    copy(dst, src)
    return dst
}

我的经验是：临时窗口优先收紧容量，跨层传递或需要长期保存的数据直接复制。这样代码的所有权意图更清楚，也不会因为上游一次 make 的容量变化而出现“这次复现、下次不复现”的问题。

常见问题

append 一定会修改原切片吗？

不一定。容量足够时可能复用底层数组；容量不足时会得到新数组。原切片变量本身的 len 不会因另一个切片 append 自动增长，但共享区域里的元素可能被改写。

把子切片传给函数就一定不安全吗？

不一定，风险取决于函数是否写入元素或 append，以及双方是否约定共享存储。明确借用关系并用三索引切片或复制控制边界即可。

为什么只改 len 不能防止尾部覆盖？

len 只决定当前可见元素数，append 还会检查 cap。普通二索引切片可能拥有更大的 cap，只有把第三个索引设为当前 len，才能限制它的增长空间。