Go slices.Chunk 怎样把切片分成固定大小的数据块

需要把一批切片数据交给分页、批量写入或消息发送逻辑时，最容易写出一段重复的下标循环。Go 1.23 的 slices.Chunk 可以把这件事收敛为“按上限产生连续子切片”：调用方用 range 消费迭代器，每一块最多 n 个元素，最后一块可以不足。

先记住结论： slices.Chunk(s, n) 返回的是 iter.Seq[Slice]，不是已经分配好的二维切片；空输入不会产生空块，n 会触发 panic，并且返回的每个子切片都被裁到 cap == len 的边界。

官方文档：https://pkg.go.dev/slices#Chunk

先看清 Chunk 返回的是什么

这个 API 的签名如下：

func Chunk[Slice ~[]E, E any](s Slice, n int) iter.Seq[Slice]

Slice ~[]E 让命名切片类型也能保留自己的类型；返回值是一个单值迭代器。它表达的是“以后可以逐个拿到 Slice”，因此不用先把所有块收集成 [][]T 才能处理。

用 range 逐块消费固定大小的数据

最直接的写法是对 slices.Chunk 的结果使用 range。下面的示例把七条订单按三条一组交给批处理函数：

package main

import (
    "fmt"
    "slices"
)

func main() {
    orders := []string{"A01", "A02", "A03", "A04", "A05", "A06", "A07"}

    // n 表示每个块允许容纳的最大元素数。
    for batchNo, batch := range slices.Chunk(orders, 3) {
        // 这里的 batch 是连续子切片，最后一块可以不足 3 条。
        fmt.Printf("批次 %d: %v\\n", batchNo+1, batch)
    }
}

这个例子会得到三个连续块：前两块各有三条，最后一块只有一条。批处理函数可以直接接收 batch，不需要再维护 start 和 end 两个下标。

尾块和空输入要分别处理

“固定大小”描述的是上限，不是每一块都必须恰好等于 n。当输入长度不能整除 n 时，最后一块只包含剩余元素；当输入为空时，序列直接结束，不会多出一个长度为零的块。

package main

import (
    "fmt"
    "slices"
)

func printChunkShape(values []int, size int) {
    // range 不会进入循环，正好表示空输入没有空块。
    for i, chunk := range slices.Chunk(values, size) {
        // len 用来决定本批真正要处理的元素数量。
        fmt.Printf("第 %d 块：len=%d, cap=%d\\n", i+1, len(chunk), cap(chunk))
    }
}

func main() {
    printChunkShape([]int{1, 2, 3, 4, 5, 6, 7}, 3)
    printChunkShape(nil, 3)
}

对于长度为 7、块大小为 3 的输入，块长度是 3/3/1；对于 nil 或空切片，循环体一次也不执行。若业务必须“凑满一批才提交”，应该在循环内部明确判断 len(chunk)，不能假设每个块都完整。

为什么返回块的 cap 不会越过自身 len

普通切片表达式可能让一个子切片继续通过 append 改写同一底层数组的后续位置。slices.Chunk 对每个返回块做了容量裁剪，官方语义是“capacity 不超过 length”。这让块的边界更适合交给独立的处理函数。

package main

import (
    "fmt"
    "slices"
)

func main() {
    source := []int{10, 20, 30, 40, 50}

    for chunk := range slices.Chunk(source, 2) {
        // Chunk 返回的每块都把 cap 限制在 len，先记录边界再处理数据。
        fmt.Printf("values=%v len=%d cap=%d\\n", chunk, len(chunk), cap(chunk))
    }
}

这里的容量约束不是“深拷贝”：元素仍然来自原切片的底层存储，修改元素本身仍要遵守共享数据的约定。它解决的是块继续向右扩容的边界问题，不等于为每一块复制出一份新数组。

把 n 参数变成明确的批处理约束

n 小于 1 不是“返回空结果”，而是 API 使用错误。若大小来自配置、请求参数或环境变量，应该在调用前拦截，并把错误交给上层，而不是让 panic 直接穿透服务边界：

package main

import (
    "errors"
    "fmt"
    "iter"
    "slices"
)

var errInvalidChunkSize = errors.New("chunk size must be positive")

func batches[T any](values []T, size int) (iter.Seq[[]T], error) {
    // 外部输入先校验，避免 slices.Chunk 因 n

泛型辅助函数保留了 iter.Seq[[]T] 的消费方式；如果项目不需要把错误传回更远的边界，也可以在配置加载阶段保证大小为正，再直接调用 slices.Chunk。

四个容易混淆的判断

写在批处理代码里的最小结论

如果目标只是把一段切片按上限分批，优先写成 for chunk := range slices.Chunk(values, size)。在循环里按 len(chunk) 处理尾块，调用前保证 size > 0，不要把返回块误认为深拷贝，也不要期待空输入产生一个“空批次”。这四点就覆盖了这个 API 最容易造成误会的部分。

相关问题

• slices.Chunk 能否直接用于命名切片类型？ 可以，签名中的 Slice ~[]E 允许底层类型为切片的命名类型参与推导。
• 如何得到二维切片？ 只有在确实需要长期保存所有块时，才在循环里显式 append；即时处理通常直接消费迭代器即可。
• 尾块要不要补零？ API 不会自动补齐；是否补齐属于业务协议，应在拿到尾块后单独实现。