Go range over func 怎样让函数迭代器支持提前停止在批处理代码中减少额外分配

我在把批量筛选代码改成函数迭代器时，最先遇到的不是语法问题，而是提前退出：消费者已经拿够了一批数据，生产端却还在继续遍历。Go 1.23 起，range over func 可以用 yield 的布尔返回值把这个停止信号传回迭代器。只要迭代器正确处理 false，就能避免为了筛选结果先创建完整的中间切片；这能减少一类额外分配，但不等于任何场景都保证零分配。

官方地址：https://pkg.go.dev/iter

本文使用 Go 1.23 引入的 iter.Seq，示例围绕“批处理达到上限就停止”这一件事展开，不讨论并发消费者或基准测试数字。

先看现象：消费者停了，生产端也应该停

传统写法通常是先把满足条件的记录收集到新切片，再交给批处理函数。数据量大时，这个中间切片会带来额外容量和拷贝；如果调用方只需要前几个批次，后面的记录也没有必要继续扫描。

range over func 把迭代器写成一个接受回调的函数。消费者执行 break 后，运行时会让下一次 yield 返回 false。迭代器必须看到这个返回值就结束自己的函数，否则继续调用已经拒绝后续值的 yield 会违反迭代器约定。

range over func 的停止协议到底是什么

iter.Seq[V] 的形状是 func(yield func(V) bool)。yield 返回 true 表示消费者还要下一个值，返回 false 表示消费者已经停止。这个返回值不是业务字段，也不是错误对象，而是消费生命周期的边界。

// Scan 返回一个可被 range 消费的整数迭代器。
func Scan(values []int) iter.Seq[int] {
	return func(yield func(int) bool) {
		for _, value := range values {
			// false 说明调用方已经 break，生产端必须立即返回。
			if !yield(value) {
				return
			}
		}
	}
}

这里的 return 很关键。它让底层函数在消费者停止后及时结束；如果迭代器还包着文件读取、分页游标或资源释放逻辑，也应把清理放在这个函数能够到达的收尾位置。

把批处理函数改成可提前停止的迭代器

批处理不一定要先生成 [][]Record。下面的函数直接从原始切片取出批次视图，并通过 iter.Seq[[]Record] 推送给调用方。切片表达式只描述原底层数组的一段范围，示例没有为了“全部批次”再物化一个结果集合。

package main

import "iter"

type Record struct {
	ID    int
	Valid bool
}

// Batches 按 batchSize 暴露原切片的批次视图，不预先创建批次集合。
func Batches(records []Record, batchSize int) iter.Seq[[]Record] {
	return func(yield func([]Record) bool) {
		if batchSize  len(records) {
				end = len(records)
			}
			// 发送批次视图；false 表示调用方不再需要后续批次。
			if !yield(records[start:end]) {
				return
			}
		}
	}
}

这个实现的收益点是边界清楚：输入仍是 records，每个批次是切片视图，消费者是否继续由 yield 决定。它没有把“避免中间切片”偷换成“所有调用都更快”，因为批次大小、下游处理、逃逸分析和实际数据都会影响结果。

消费端达到上限后怎样安全停止

调用方可以像遍历普通集合一样使用这个迭代器。达到批次数量上限后执行 break，停止信号会沿着 yield 返回到 Batches，后面的批次不会继续产生。

// TakeValidBatches 只处理前 maxBatches 个含有效记录的批次。
func TakeValidBatches(records []Record, batchSize, maxBatches int) int {
	processed := 0
	if maxBatches = maxBatches {
			// break 会让底层 Batches 收到 yield=false 并返回。
			break
		}
	}
	return processed
}

如果迭代器内部还持有需要显式关闭的资源，应在迭代器函数内部用 defer 注册清理，或者改用标准库的 iter.Pull 并在消费端拿到 stop 后立即 defer stop()。单纯依赖 break 不会替你关闭一个自定义资源。

减少了什么开销，哪些结论不能直接下

我会把这类改造的判断标准定成三条：调用方是否真的经常提前结束，原实现是否先物化了不必要的集合，以及输入切片是否可以接受被批次视图继续引用。若这三点都成立，iter.Seq 通常值得试；如果遍历本身很短，普通 for 循环可能更容易读。

相关问题

为什么迭代器不能忽略 yield 的 false？

因为 false 就是消费者停止的协议。继续调用 yield 会让迭代器越过消费边界，标准迭代器约定还明确禁止在 yield 返回 false 后再次调用它。

range over func 是不是一定比返回切片快？

不是。它主要减少中间结果物化并支持提前停止；是否更快要结合数据规模、下游保存方式和基准测试判断。

批次切片视图有什么生命周期风险？

批次仍引用原始数组。若把批次异步保存或跨越原数据预期生命周期使用，应重新评估拷贝、所有权和并发访问边界。