Go iter.Pull 怎样把推送式迭代转换成逐项读取处理空输入并保留错误边界

我第一次把 iter.Seq 接到一个需要“每次只取一条”的消费函数时，最容易误判的地方不是语法，而是结束条件：next 返回的零值并不代表输入里真的有一个零值元素，必须同时看第二个 bool。另外，读到一半就返回时，不能只丢掉函数，还要调用 stop。

在 Go 1.23 及更高版本中，iter.Pull 可以把推送式序列转换成 next 和 stop 两个函数。下面用一个带“正常值、空输入、可预期错误”的小例子，把这几个边界放在一起处理。

核心写法是：拿到 next, stop := iter.Pull(seq) 后立即 defer stop()；每轮先调用 v, ok := next()，只在 ok 为 true 时使用 v。iter.Pull 本身没有 error 返回位，业务错误要通过元素类型或外部状态显式保留。

先看清推送式和逐项读取的分工

iter.Seq[V] 接收一个 yield func(V) bool，源迭代器主动把值交给 yield，这是推送式。iter.Pull 反过来提供 next() (V, bool)，由调用方决定什么时候取下一项；stop() 则负责在还没读完时通知源迭代器停止。

这两种模型适合不同的调用方：连续处理全部元素时，for range 更自然；需要和另一个序列同步读取、按需取一项或中途停止时，pull 形式更容易组织控制流。

用 next 正确处理普通输入和空输入

先把切片包装成一个最小的 iter.Seq[int]。示例中故意保留 0，用来说明不能只判断返回值本身。

package main

import (
	"fmt"
	"iter"
)

// sliceSeq 把切片转换成推送式序列；yield 返回 false 时立即停止继续发送。
func sliceSeq(values []int) iter.Seq[int] {
	return func(yield func(int) bool) {
		for _, value := range values {
			// 由调用方决定是否继续消费，避免无意义地发送后续元素。
			if !yield(value) {
				return
			}
		}
	}
}

func readAll(values []int) []int {
	next, stop := iter.Pull(sliceSeq(values))
	defer stop() // 空输入、读完或提前返回都统一执行清理。

	var result []int
	for {
		value, ok := next()
		if !ok {
			break // false 才表示序列结束，不能用 value == 0 判断。
		}
		result = append(result, value)
	}
	return result
}

func main() {
	fmt.Println(readAll([]int{0, 7, 9})) // [0 7 9]
	fmt.Println(readAll(nil))            // []
}

这里的空输入不会报错，第一次调用 next 就得到元素类型的零值和 false。即使序列已经结束，继续调用 next 也会保持“零值加 false”的结果；但把 stop 放在 defer 中仍然更稳妥，也让后续改成提前返回时不容易漏清理。

提前退出时为什么一定要 stop

真实的源迭代器可能在内部启动工作、持有临时对象，或者在 yield 返回 false 时做收尾。如果消费方只读到第三条就返回，而没有调用 stop，源迭代器就没有机会收到“不要继续”的信号。

func firstTwo(values []int) ([]int, error) {
	next, stop := iter.Pull(sliceSeq(values))
	defer stop() // 提前返回也会触发 stop，给源迭代器收尾机会。

	result := make([]int, 0, 2)
	for len(result) 

stop 可以重复调用，也可以在 next 已经返回 false 后调用，所以把它统一写成 defer stop() 不需要额外维护“是否读完”的布尔变量。

让业务错误和迭代结束各自有位置

iter.Pull 的返回值只有“元素”和“是否有效”，没有单独的 error。因此不要把业务错误偷偷编码成某个特殊整数，也不要把 ok == false 当成错误。更容易维护的办法是让元素本身携带错误信息：

type record struct {
	Value int
	Err   error
}

func recordSeq(records []record) iter.Seq[record] {
	return func(yield func(record) bool) {
		for _, item := range records {
			// 错误作为数据的一部分传递，结束信号仍由 bool 表示。
			if !yield(item) {
				return
			}
		}
	}
}

func readUntilError(records []record) ([]int, error) {
	next, stop := iter.Pull(recordSeq(records))
	defer stop() // 错误返回和正常结束都经过同一条清理路径。

	var values []int
	for {
		item, ok := next()
		if !ok {
			return values, nil // 没有错误且读完，才是正常成功。
		}
		if item.Err != nil {
			return values, item.Err // 业务错误不与迭代结束混淆。
		}
		values = append(values, item.Value)
	}
}

如果源迭代器发生 panic，官方契约是这个 panic 会从 next 或 stop 继续传出；它不是可通过 ok 判断的业务错误。需要把异常转换为可恢复错误时，应在源迭代器边界内明确捕获并生成 record{Err: ...}，而不是期待 iter.Pull 自动完成转换。

上线前记住三个边界

• 零值不等于结束：必须同时检查 ok，因为合法元素可以就是类型零值。
• 提前停止要清理：拿到 next 后立即 defer stop()，不要把清理留给调用方记忆。
• 不要并发调用：next 和 stop 不能被多个 goroutine 同时调用；需要并发时，在单一 pull 消费者外层做分发。

所以，iter.Pull 适合把“由源主动推送”的序列接到需要逐项控制的代码上。它解决的是消费方式，不会替业务设计错误模型；只要把结束、停止和错误三件事分开，空输入和提前返回就不会再互相混淆。

相关问题

iter.Pull 能不能直接返回 error？不能。它的函数签名只包含元素和有效标记，错误需要通过元素结构、外部状态或其他业务协议表达。

读到末尾后还要调用 stop 吗？可以不调用，但统一使用 defer stop() 更不容易在以后增加提前返回分支时遗漏清理。

空切片和 nil 切片有什么区别？对这个示例的迭代结果没有区别，二者都会在第一次 next 时返回零值和 false。