-
一次对 Go slice 做切片后 append,意外覆盖了原始 slice 里的数据,让一份订单列表凭空窜了值:一次共享底层数组的深度复盘
只往一段子切片里 append 了几个元素,原始订单 slice 紧挨其后的数据却被莫名其妙改掉了。根因是 Go 的 slice 切片(s[0:3])不复制数据、和原 slice 共享同一底层数组,且子切片的 cap 到底层数组末尾、有剩余容量,append 便原地写入、覆盖了原 slice 的元素;而 cap 不够时 append 会扩容分配新数组、不影响原数组——故行为时灵时不灵、极难复现。本…- 7
- 0
-
我从一个大切片里截了个子切片,往子切片 append 了个元素,结果原切片里好端端的数据竟被悄悄改掉了,我对着 Go 切片 append 共享底层数组这个坑排查大半天的复盘
一个让我对 Go slice 又爱又怕的经典坑,可怕在代码逻辑上看不出破绽、数据却在你没动它的情况下被悄悄改掉。需求很普通:有个存原始数据的大切片,从中截一段做处理、处理时会往子切片 append 新元素。我写 original := []int{1,2,3,4,5};sub := original[0:3];sub = append(sub, 999)。打印发现 sub 是 [1 2 3 999…- 0
- 0
-
我只是对一个切片做了 append,结果它悄悄改掉了另一个切片的数据,我盯着这个幽灵修改查了大半天才搞懂共享底层数组的深度复盘
我从一个切片 s 上用 sub := s[1:3] 切出子切片,以为 sub 是独立的、改它不影响 s。结果对 sub 做了 append 后,回头一看 s,它某个元素竟被悄悄改掉了——我一个字都没碰 s!深挖才懂:Go 切片本质是"底层数组的视图",由 (ptr,len,cap) 组成,子切片和原切片共享同一个底层数组、没复制数据;sub 的 cap 还够时 append 不…- 2
- 0
-
我只是往一个切片里 append 了个元素,另一个切片的数据却被我悄悄改了:Go 切片共享底层数组的坑,让我排查了一下午
我只对子切片 sub 做了 append(sub, 999),从没碰过原始切片 original,可 original[3] 却从 4 被悄悄改成了 999。排查一下午才搞懂:Go 切片是 (ptr, len, cap) 三件套、是底层数组的视图,sub := original[0:3] 时两者共享底层数组且 sub 的 cap 仍是 5;append 发现容量富余,就直接写进了共享数组、覆盖了 …- 7
- 0
-
从大切片切出一小段传出去处理,函数只 append 了几下我原始切片的数据却被悄悄串改了:Go 切片共享底层数组的数据污染避坑复盘
这是一个我改了 A、B 却莫名其妙也变了的诡异数据污染 bug,排查时让我对 Go 的切片产生了深深的敬畏。事情是这样的:我有一个切片装着一批数据,我从它里面切出一小段子切片传给另一个函数去处理,那个函数对子切片做了点 append 操作,我满以为它是在自己手里的那一小段上追加跟原来那个大切片八竿子打不着,可结果是函数处理完之后我那个原始的大切片里面的数据被悄悄地莫名其妙地改掉了几个。我明明只把一…- 0
- 0
-
改一段切片污染另一段:Go slice 底层数组避坑
有个 Go 服务处理一批数据时有这么个逻辑:从一个大切片里按条件切出几段子切片分别交给不同业务处理,其中一段会被追加新元素、另一段会被原地修改,代码写得清清爽爽测试也过了便上线。可线上偶尔冒出灵异现象:某一段数据会莫名其妙出现本不该属于它的内容,像是被另一段处理串味了,复现概率不高数据也对不上、排查好几天毫无头绪——两段切片在代码里明明独立处理八竿子打不着怎么会互相影响?直到把切片底层机制重新啃了…- 11
- 0
底层数组
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×