这是底层数组共享的必然结果：子切片通过s[i:j]创建后与原切片共用同一底层数组，修改子切片元素会直接改写原数组对应位置，未扩容时所有共享该数组的切片均相互影响。
Go 中 slice 修改一个子切片，原始切片内容跟着变——这不是 bug，是底层数组共享的必然结果。只要没触发 append 扩容，所有共享同一底层数组的 slice 都会相互影响。
子切片赋值直接污染原数组
这是最典型、最容易复现的数据污染场景：通过 s[i:j] 创建子切片后，对子切片元素做赋值操作，会直接改写原底层数组对应位置。
-
s1 := []int{1, 2, 3}→ 底层数组为[1 2 3]，cap=3 -
s2 := s1[1:2]→s2指向同一数组，起始偏移为 1，len=1，cap=2 -
s2[0] = 100→ 实际修改的是底层数组索引 1 的值，s1变成[1 100 3]
这种行为在日志解析、协议字段提取等场景中极易引发静默错误：比如从大缓冲区 buf 中切出 header := buf[:8]，再把 header[0] = 0xff 当作标记，结果整个 buf 的第一个字节也被改了。
函数参数传入子切片引发副作用
当函数接收一个子切片并对其调用 append，是否影响调用方，取决于当时容量是否足够——这使得行为不可预测，调试困难。
- 若传入
s[:2]（cap=5），函数内append(s, x)未扩容 → 原数组被写入，调用方可见变化 - 若传入
s[:4]（cap=4），append必然扩容 → 新建底层数组，调用方不受影响 - 函数签名看似“只读”，实际可能产生写副作用，违反直觉
常见于封装解析逻辑时：比如 parseHeader(data []byte) 内部做了 data = append(data, 0) 补零，若传入的是大包体的子切片，就可能意外污染原始数据流。
循环中反复切片却长期持有引用
批量处理时用 for _, v := range data 然后 slice := src[v.start:v.end] 收集到 [][]byte，所有子切片都指向同一个 src 底层数组。
- 一旦
src是局部变量（如函数内readAll()返回的大[]byte），函数返回后该数组本该被 GC，但因子切片仍引用着它，整块内存钉死不释放 - 更糟的是，这些子切片之间也共享内存：修改
results[0][0]可能覆盖results[1][0]对应的原始位置 - HTTP body 解析、Protobuf 字段提取、数据库
rows.Scan(&buf)后再切分，都是高危区
这类泄漏不会报错，只会让 pprof 显示大量长期驻留的 []uint8，且大小等于原始输入（比如几 MB 的文件内容），而非你真正需要的几十字节。
如何安全切断底层数组引用
核心原则：显式拷贝真正需要的数据，不依赖切片语法的“视图”特性。
- 用
make([]T, len(src))+copy(dst, src)：语义清晰，零歧义，推荐用于关键路径 - 用
append([]T{}, src...)：简洁，但会触发一次分配和复制，适合小数据 - Go 1.20+ 可用
bytes.Clone(src)（仅限[]byte）：专为此设计，可读性最强 - 绝对避免
src[:]或src[0:len(src)]“重置”——这只是调整头信息，不释放底层数组
真正容易被忽略的点在于：不是所有子切片都需要深拷贝，但只要它生命周期比原始数据长（比如存进 map、channel、全局变量或返回给调用方），就必须切断。这个判断不能靠经验猜，得看数据流向和作用域边界。
