Go iter.Seq 怎样给自定义集合提供范围迭代器在批处理代码中减少额外分配

批处理代码经常需要把自定义集合中的记录逐个交给处理函数。传统写法通常先调用一个返回新切片的方法，再进入 for range；集合较大或批次频繁时，这个中间切片就是额外分配。Go 1.23 起，函数类型可以参与范围遍历，iter.Seq 正好把“逐项提供数据”的约定标准化。

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

结论是：让集合方法返回 iter.Seq[T]，在迭代器内部逐项调用 yield，并在 yield 返回 false 时立即停止。这样调用方可以直接 for item := range collection.All()，不必为了遍历复制一份集合；但它减少的是中间容器分配，不等于所有场景都零分配。

先看清 iter.Seq 的两个函数边界

iter.Seq[T] 的本质是 func(yield func(T) bool)。外层函数描述“怎样产生一串值”，内层的 yield 负责接收当前值；接收方返回 true 才继续，返回 false 就表示已经不需要后续数据。

package main

import "iter"

// consume 只消费调用方需要的前几项，false 会让生产端停止。
func consume[T any](seq iter.Seq[T], limit int) int {
	count := 0
	for value := range seq {
		_ = value // 示例只关注迭代边界，实际代码可在这里处理 value。
		count++
		if count == limit {
			break // range 的 break 会让 yield 返回 false。
		}
	}
	return count
}

这里最关键的不是“函数套函数”，而是停止信号必须沿着调用链返回。迭代器不能在 yield 已经返回 false 后继续调用它，否则就破坏了 iter 包约定。

让自定义集合直接暴露范围迭代器

下面用一个按页保存任务的集合演示。All 返回完整集合的迭代器，Range 只暴露半开区间 [start,end)。实现直接读取底层切片，不先执行 append([]Task(nil), ...) 之类的复制操作。

package taskset

import "iter"

type Task struct {
	ID   int
	Name string
}

type Tasks struct {
	items []Task
}

// All 返回当前集合的只读遍历视图；调用方可以直接对结果使用 range。
func (t Tasks) All() iter.Seq[Task] {
	return func(yield func(Task) bool) {
		for _, item := range t.items {
			if !yield(item) {
				return // 消费者提前停止时，不再读取后续元素。
			}
		}
	}
}

// Range 返回 [start, end) 区间，越界边界被收敛到当前集合长度。
func (t Tasks) Range(start, end int) iter.Seq[Task] {
	return func(yield func(Task) bool) {
		if start  len(t.items) {
			end = len(t.items) // 超过长度时只遍历现有元素。
		}
		if start >= end {
			return // 空范围不调用 yield。
		}
		for _, item := range t.items[start:end] {
			if !yield(item) {
				return // 处理方 break 后立刻收口。
			}
		}
	}
}

值接收者让迭代器捕获的是 items 切片描述符，而不是把每个元素复制到新集合。元素本身仍会按值传给 yield；如果元素很大，可以把集合元素设计为指针或轻量句柄，但这属于数据模型取舍。

在批处理里利用提前停止，而不是先切片

批处理通常不是“永远消费全部数据”：达到本轮配额、遇到截止时间或处理器返回失败时都可能停止。把这些判断写在消费者侧，生产端只负责尊重 false，就能减少无用读取和中间结果。

package main

// processBatch 只处理当前批次需要的数量，避免先生成完整临时切片。
func processBatch(tasks Tasks, start, end, quota int) int {
	processed := 0
	for task := range tasks.Range(start, end) {
		if !handle(task) {
			break // 业务失败时停止继续读取。
		}
		processed++
		if processed >= quota {
			break // 达到批次配额，迭代器收到 false 后结束。
		}
	}
	return processed
}

// handle 代表实际的单项处理逻辑；这里用固定返回值保持示例可读。
func handle(task Task) bool {
	_ = task
	return true
}

这种写法的收益是结构性的：没有为了“取一段数据”而创建第二个切片，也不会在消费者已经停止后继续遍历剩余元素。若每个任务仍会触发网络请求、序列化或日志创建，主要成本依旧来自这些操作，不能把所有性能提升归因于 iter.Seq。

减少分配的边界：能省什么，不能省什么

首先，iter.Seq 不保证零分配。返回闭包可能因捕获变量而产生逃逸，元素按值传递也可能复制较大的结构体；并发修改底层切片还会引入数据竞争。它更适合表达“只读、顺序、可提前停止”的访问协议。

实践中可以按下面的顺序判断：

• 如果调用方总要修改、排序或重复随机访问，返回切片可能更直接。
• 如果集合来自不可回放的数据流，必须在文档中说明迭代器是单次使用。
• 如果要把 push 迭代器改成逐项拉取，再考虑 iter.Pull，并在提前结束时调用返回的 stop。
• 如果集合会被并发写入，先建立快照或加同步，不能把迭代器当成并发安全层。

是否真的减少了分配，应使用基准测试比较“复制后 range”和“直接 range over Seq”两条路径，并观察 -benchmem 的分配次数与字节数。不要只看一次运行时间，更不要把未执行的估算写成固定百分比。

给接口留下可维护的约定

集合方法优先使用 All 表示完整遍历，带筛选条件时用能表达边界的名称，例如 Range。文档要写清顺序、是否可重复调用、元素是值还是指针、底层集合能否在遍历期间修改，以及 yield=false 后是否还需要释放资源。

最后用一句话复盘：iter.Seq 把自定义集合接入 Go 的范围遍历协议，适合把批处理的“读取多少、何时停”交给消费者决定；它可以消除临时切片这一类额外分配，但仍需用基准测试确认闭包、元素大小和真实业务成本。

相关问题

iter.Seq 和返回切片怎么选？只读顺序消费、可能提前停止时优先考虑 iter.Seq；需要排序、索引或多次随机访问时，切片通常更合适。

为什么 break 能让集合停止遍历？范围循环会把停止状态传回 yield，集合迭代器检查到 false 后立即返回。

什么时候要使用 iter.Pull？当调用方天然是“请求一个、处理一个”的拉取协议，或需要把两个序列交错消费时，再用 iter.Pull，并确保结束时调用 stop。