slices.Chunk 如何把批量写入拆成固定大小分组

我以前给数据库批量写入做分组，通常会手写 for start := 0; start ，然后再计算结束下标。Go 1.23 加入迭代器后，标准库提供了 slices.Chunk：它把一个切片按最多 n 个元素分成连续子切片，并返回可直接 range 的 iter.Seq。

批量写入时可以直接写 for batch := range slices.Chunk(rows, batchSize)。除最后一组外，每组长度都是 batchSize；最后一组可以更短。空切片不会产出任何组，batchSize 小于 1 会 panic。

为什么这类分组写法正在变得更常用

Go 1.23 把迭代器协议引入语言和标准库后，slices.Chunk、slices.All、slices.Values 等函数开始把“遍历方式”从手写下标循环里抽出来。官方文档确认 Chunk 返回 iter.Seq[Slice]，调用方可以按需消费，而不是先建立一个 [][]T 保存全部分组。

对批量写入来说，这解决的不是一个复杂算法问题，而是三个反复出现的小问题：结束下标容易写错、最后一批不足上限时容易遗漏、每个项目都会重复一段近似的切片代码。标准库统一后，代码评审可以把注意力放到批量大小、失败语义和事务范围上。

最小写法：按固定上限拆分切片

package main

import (
	"fmt"
	"slices"
)

func main() {
	rows := []int{101, 102, 103, 104, 105, 106, 107}

	// 每次最多取得 3 条；最后一组可以少于 3 条。
	for batch := range slices.Chunk(rows, 3) {
		fmt.Println(batch)
	}
}

这里会依次得到长度为 3、3、1 的三个子切片。Chunk 保留原顺序，不会补齐最后一组，也不会为一个空输入额外产出空切片。这个行为很适合数据库批量插入、HTTP 批量接口、消息队列批量发送和文件分段处理。

把 Chunk 接到真实批量写入函数

真正的工程代码不能只循环打印。对我来说，一个可用的封装至少要做四件事：校验批量大小、在首个失败处停止、返回已成功写入数量，并给错误加上批次位置。下面用接口隔离具体数据库实现，MySQL、PostgreSQL、HTTP 客户端或消息生产者都可以套用同一结构。

package batchwrite

import (
	"context"
	"fmt"
	"slices"
)

type Row struct {
	ID   int64
	Name string
}

type Repository interface {
	InsertBatch(ctx context.Context, rows []Row) error
}

func WriteInBatches(
	ctx context.Context,
	repo Repository,
	rows []Row,
	batchSize int,
) (int, error) {
	// Chunk 在 n 小于 1 时会 panic，因此先把配置错误转成普通错误。
	if batchSize 

这个返回值设计刻意不假装“全部成功”。例如第三批失败时，调用方能知道前两批已经写入多少条。是否重试、是否回滚，要由更上层根据幂等键、唯一约束和事务模型决定。单纯把整个循环包在重试里，可能重复提交前面已经成功的分组。

最容易忽略的风险：分组并没有复制元素

slices.Chunk 返回的是原切片的连续子切片，不是深拷贝。修改分组中的现有元素，会同步修改原切片。官方实现还会把每个子切片的容量裁到它的长度，因此对分组执行 append 时会分配新的底层数组，不会顺手覆盖相邻分组。

package main

import (
	"fmt"
	"slices"
)

func main() {
	values := []int{1, 2, 3, 4}

	for part := range slices.Chunk(values, 2) {
		// 修改已有元素仍会反映到原切片，因为两者共享元素存储。
		part[0] *= 10

		// 每个 part 的 cap 等于 len，append 不会覆盖后面的分组。
		expanded := append(part, 99)
		fmt.Println(part, expanded)
	}

	fmt.Println(values)
}

这项设计对批量写入通常是好事：没有额外的分组复制成本，而且能避免对某组 append 时破坏相邻数据。但如果底层写入函数会原地修改结构体字段，或者把 batch 保存到异步任务里，而原切片随后又被复用，就需要在边界处用 slices.Clone(batch) 建立独立副本。

谁会受益，谁需要保持谨慎

最直接受益的是服务层和数据访问层。它们经常面对服务端单次参数上限、SQL 占位符上限、请求体大小或队列批次上限。用 Chunk 可以把分组策略集中在一处，并让底层接口只处理“一批数据”。

库作者也会受益。参数类型保留了命名切片类型，调用方不用先转换成普通 []T；返回迭代器则允许调用者提前停止消费。但 Go 1.22 及更早版本不能直接使用这套标准库迭代器 API，维护多版本库时仍要保留手写循环或提高最低 Go 版本。

需要谨慎的是事务敏感和并发写入场景。Chunk 只负责分组，不负责事务、限流、并发数、顺序保证、重试或幂等。把每一组并发提交会改变错误语义和服务端压力，不能因为分组代码变短就默认开启 goroutine。

批量大小应该怎样选择

不存在通用的最佳 batchSize。我通常先从服务端明确限制倒推：SQL 参数数量、请求体字节数、消息系统单批上限、连接超时和事务日志压力。然后选一个保守值上线，通过指标再调，而不是只按“每批 1000 条”这种经验数字固定到底。

• 每批实际条数：确认大部分分组接近目标值，尾批分布是否合理。
• 单批耗时：观察 P50、P95、P99，避免大批次拉长尾延迟。
• 失败批次索引和已写数量：支持定位部分成功。
• 重试次数与重复键错误：判断幂等策略是否可靠。
• 请求体字节数和内存：元素大小差异很大时，固定条数未必等于固定负载。

这也是我认为 slices.Chunk 最合适的采用路径：先替换稳定、串行、可重试的手写分组循环；再把批量大小提到配置层并补齐指标；最后才评估并发提交和事务范围。它让机械代码更少，但不会替代这些工程判断。

常见问题

需要先把 Chunk 结果收集成 [][]T 吗？

通常不需要。Chunk 返回迭代器，可以边取得分组边写入，避免额外保存所有分组。只有确实需要随机访问、重复遍历或跨生命周期保存时，才考虑收集并按需要克隆。

空切片会调用一次 InsertBatch 吗？

不会。空输入对应空序列，循环体一次也不执行，函数会直接返回已写数量 0 和 nil 错误。

可以在多个 goroutine 中并发写每个分组吗？

技术上可以把分组交给受控工作池，但那属于另一层设计。必须先确认 Repository 是否并发安全、服务端是否允许并发批量请求、错误如何聚合、是否要求顺序，以及取消后如何停止未提交任务。

slices.Chunk 的价值并不在于省掉几行下标计算，而在于把“连续、固定上限、尾批可变”的分组语义交给标准库。剩下的错误、事务、幂等和指标仍由业务负责；把这条边界守住，批量写入代码才会既短又可靠。