Go slices.Chunk 分组后为什么还能改到原切片：子切片共享数组的边界

批量处理订单时，代码常把一个大切片交给 slices.Chunk 分组，再把每组交给不同函数。如果后续函数改了分组里的元素，原切片也跟着变，这通常不是迭代器失效，而是子切片仍然指向同一块底层数组。

slices.Chunk 返回的是原切片的连续子切片，不会自动复制元素；要让分组独立保存，需在写入前对每组调用 slices.Clone。

先看一个会回写原切片的分组

下面的例子把四个订单号按两个一组遍历。group[0] = 900 修改的是分组视图中的第一个元素，打印 orders 时可以看到第一个订单号已经改变。

package main

import (
    "fmt"
    "slices"
)

func main() {
    orders := []int{101, 102, 103, 104}
    for group := range slices.Chunk(orders, 2) {
        if group[0] == 101 {
            group[0] = 900
        }
        fmt.Println("group:", group)
    }
    fmt.Println("orders:", orders)
}

输出中的 orders: [900 102 103 104] 是关键证据：分组没有创建第二份元素数组，group 与 orders 共享底层存储。

这个模式为什么安全地限制了追加范围

slices.Chunk 的每个结果组都被裁成“长度等于容量”。因此在第一组 [101 102] 上执行 append(group, 105) 时，追加操作不能直接写进第二组的位置，而是会分配新的底层数组。

这解决的是“追加越界覆盖下一组”的问题，不改变“修改现有元素会回写”的事实。可以把它理解成两条规则：group[0] 仍走共享数组；append(group, 105) 因容量不足而走 new array。

orders := []int{101, 102, 103, 104}
for group := range slices.Chunk(orders, 2) {
    group = append(group, 105)
    fmt.Println("group:", group)
}
fmt.Println("orders:", orders)

这里的输出会保留原来的 orders，但不能据此推断所有修改都安全；索引赋值与追加是不同的操作路径。

需要独立分组时复制元素

如果分组函数要排序、补字段或暂存后续修改，直接使用 group 会让副作用回到 orders。最小改法是复制每一组，再把副本交给会修改数据的函数。

for group := range slices.Chunk(orders, 2) {
    isolated := slices.Clone(group)
    isolated[0] = 900
    fmt.Println("isolated:", isolated)
}
fmt.Println("orders:", orders)

slices.Clone 复制的是元素序列；它不是深拷贝。如果元素类型是指针、包含 map，或结构体字段里仍有引用型数据，还要根据业务需要继续复制内部对象。

边界与判断清单

• n ：调用会 panic，批处理参数应在进入循环前校验。
• 空切片：迭代器没有任何分组，不会回调出一个空组。
• 只读遍历：直接使用 group 没问题；会改元素时优先 slices.Clone。
• 元素含引用：先区分“复制切片”与“复制对象图”，不要把 Clone 当成深拷贝。

相关问题

slices.Chunk 会返回新的二维切片吗？

不会。它返回一个迭代器，每次产出一个连续子切片；子切片的元素来自输入切片。

为什么 append(group, value) 没有改掉下一组？

每组的容量被裁到不超过自身长度，追加时容量不足，通常会转到新的底层数组。

什么时候必须使用 slices.Clone？

当分组会被异步保存、排序、改写，或生命周期超过原切片的当前处理阶段时，复制一份更容易控制所有权。

小结

slices.Chunk 解决的是遍历分组，不是数据隔离。读懂“共享元素、裁剪容量、必要时 Clone”这三点，就能在批量任务中准确判断副作用来自哪里。