Go slices.Chunk 迭代分组时为什么不能改原切片：尾块、容量与遍历边界

批处理服务把 10 条订单按 3 条一组交给下游时，日志里出现过一次很难复现的“下一批少了一项”：代码刚换成 slices.Chunk，看起来只是把长切片分段，实际却在遍历子切片时改动了原数组。这个问题的关键不在于迭代器难，而在于每个分组仍然指向同一块底层存储。

先还原那次批处理异常

线上任务的输入是 10 个订单号，业务希望每批最多处理 3 个。最小写法如下：

orders := []string{"A01", "A02", "A03", "A04", "A05", "A06", "A07", "A08", "A09", "A10"}

for batch := range slices.Chunk(orders, 3) {
    fmt.Println(len(batch), batch)
}

输出会是 3、3、3、1 四批。最后一批只有一个元素，不会为了凑满 3 个而填充零值；输入为空时，循环一次也不会进入。这个行为很适合批量请求，但也意味着业务必须把尾块当成正常分支，而不是异常数据。

分组按原顺序连续切开，尾块长度由剩余元素决定；它不是一个带空位的固定数组。

故障是怎样被触发的

排查时间线通常很短：第一步，分组读取结果正确；第二步，某个校验器为了复用缓冲区，把 batch[0] 改成规范化后的值；第三步，后续日志发现原始 orders 也变了。于是有人误以为 Chunk 返回了独立副本，继续在分组里做原地整理。

实际上，分组只是原切片的一段视图。下面的赋值会同步影响 orders[0]：

orders := []string{" a01 ", "a02", "a03", "a04"}
for batch := range slices.Chunk(orders, 3) {
    batch[0] = strings.TrimSpace(batch[0])
    break
}
fmt.Println(orders[0]) // a01

这里的“共享”只针对已有元素的读写；它不表示分组可以无限向后写。判断问题时，要把元素别名和追加容量分开看。

容量裁剪挡住了哪一种越界

官方文档明确说明，Chunk 产生的每个子切片都被裁剪到容量不超过长度。假设输入长度为 7、每组大小为 3，第二组的长度和容量都是 3，最后一组的长度和容量都是 1。这样做可以阻止下面这种追加偷偷覆盖下一组数据：

for batch := range slices.Chunk(orders, 3) {
    batch = append(batch, "temporary")
    // append 会得到新的存储或新的切片视图，
    // 不会沿着 orders 的下一段继续写入。
    _ = batch
}

容量裁剪是边界保护，不是深拷贝。若要在批次内自由修改，又不想碰原数据，应显式复制：

safeBatch := append([]string(nil), batch...)
safeBatch[0] = strings.TrimSpace(safeBatch[0])

这样复制的是当前分组的元素，代价是每批都有一次分配和拷贝。是否值得，要看下游是否会持有批次、异步处理批次，或者会修改批次里的已有位置。

原地改已有位置会回写原数组；追加则受限于分组容量，不能直接穿透到下一段。

把三个边界写进测试

这类问题不要只测“能分成几组”，还要把尾块、空输入和非法组大小一起固定下来：

func TestChunkBoundary(t *testing.T) {
    input := []int{1, 2, 3, 4, 5, 6, 7}
    var got [][]int
    for part := range slices.Chunk(input, 3) {
        got = append(got, append([]int(nil), part...))
    }

    want := [][]int{{1, 2, 3}, {4, 5, 6}, {7}}
    if !reflect.DeepEqual(got, want) {
        t.Fatalf("got %#v, want %#v", got, want)
    }
    if parts := slices.Collect(slices.Chunk([]int{}, 3)); len(parts) != 0 {
        t.Fatalf("empty input produced %d parts", len(parts))
    }
}

再补一条 n == 0 和负数的 panic 测试，避免调用方把配置文件中的空值直接传进去。若批次会跨协程或跨队列保存，测试还应确认保存的是复制后的数据，而不是原切片视图。

修复方案要按所有权来选

只读校验、同步调用下游时，直接遍历 batch 最省成本；需要规范化已有元素时，复制后再改；需要异步投递时，也建议复制后把所有权交给消费者。不要仅仅因为“看起来是一个新切片”就把它当成独立对象。

还有一个容易被忽略的点：循环变量 batch 每次都会获得新的切片值，但它们仍然覆盖同一份 orders 的不同区间。把批次收集到外层时，如果后续代码要修改内容，收集动作就应像测试示例一样显式复制。

常见问题：Chunk 的边界怎么记

最后一批不足 n 个会报错吗？

不会。最后一批可以是 1 到 n 个元素；只有 n 小于 1 时才会触发 panic。

Chunk 会复制输入切片吗？

不会。它返回的是连续子切片视图，读取没有复制成本；如果要隔离后续修改或异步使用，请自行复制。

为什么 append 后看不到下一批被覆盖？

因为每个子切片的容量被限制到长度，追加不能利用原切片下一段的剩余容量。不过这不影响对已有元素的原地修改。

空切片会得到一个空 batch 吗？

不会。空输入对应空序列，for range 不会执行循环体。

把验收结论留在代码旁边

slices.Chunk 解决的是“按顺序分批读取”，不是“为每批创建独立对象”。记住两条就够了：分组长度由剩余元素决定，分组已有元素仍与原数组共享；容量裁剪只保护追加边界，不负责隔离修改。批处理代码一旦要改值、异步投递或长时间保存，就在那个所有权交接点显式复制，并用尾块和非法参数测试把回归锁住。