Go iter.Pull 怎样把推送式遍历改成拉取式

我第一次把 Go 的函数式迭代器接到“同时读两个序列”的代码里时，最容易混淆的不是泛型，而是谁在控制下一项。iter.Seq 是推送式迭代器：它通过 yield 把值交给调用方；iter.Pull 则把这个接口转换成 next 和 stop，让普通 for 循环按需取值。

这项能力来自 Go 1.23 的迭代器支持。实际使用时可以先记住一句话：next 负责“再拿一个”，ok 负责“还有没有”，stop 负责“提前不拿了也要收尾”。

Seq 和 Pull 的控制权差在哪里

iter.Seq[V] 的形状是 func(yield func(V) bool)。序列生产者决定什么时候调用 yield，而 yield 返回 false 时，生产者应停止继续提供值。这就是推送式遍历。

如果只是把一个序列完整打印出来，直接使用 range 更自然；但当消费方需要同步比较两个序列、在拿到某个值后立刻返回，或者把迭代过程嵌进已有的普通循环时，逐项调用函数会更直观。iter.Pull 的作用就是在这两种消费方式之间加一层适配。

用 next 把两个序列放进同一个循环

下面的例子把两个 iter.Seq[int] 转成拉取函数，然后逐项比较。代码里的中文注释只标出控制权和结束条件，重点是不要把 ok 当成业务值的一部分。

package main

import "iter"

// SameSequence 比较两个序列是否按相同顺序产生相同元素。
func SameSequence(s1, s2 iter.Seq[int]) bool {
	// Pull 返回逐项读取的 next，以及负责结束底层迭代的 stop。
	next1, stop1 := iter.Pull(s1)
	defer stop1()
	next2, stop2 := iter.Pull(s2)
	defer stop2()

	for {
		// 每次只读取一个元素，适合需要同步判断的消费场景。
	v1, ok1 := next1()
		v2, ok2 := next2()
		if !ok1 {
			// 第一个序列结束时，只有第二个也结束才算相同。
			return !ok2
		}
		if ok1 != ok2 || v1 != v2 {
			// 一个结束或两个当前值不同，都可以立即结束比较。
			return false
		}
	}
}

这里的关键不是把 range 改写成更长的循环，而是把“下一项什么时候被消费”交给当前函数。ok=false 表示对应序列已经结束，不能继续把返回的零值当成有效数据。

为什么提前退出时 stop 不能省

完整读到末尾时，next 会返回 ok=false，迭代器自然结束。但很多比较、过滤和查找函数会提前 return；此时调用方没有继续拉取到末尾，底层的 yield 也就没有机会自然返回 false。

iter.Pull 因此额外返回 stop。把它放进 defer，可以覆盖“值不同立即返回”“找到目标立即返回”和“中途发生错误”的路径。官方文档把它描述为停止拉取并让底层迭代器结束；它不是可选的业务开关，而是这次适配产生的生命周期责任。

一个实用习惯是：每调用一次 iter.Pull，就在同一处紧接着安排对应的 defer stop()。不要把 stop 延迟到循环外，也不要只在“预计会提前退出”的分支里调用，因为调用方通常很快会增加新的返回路径。

什么时候保留 range，什么时候改用 Pull

我自己的取舍是：只处理一个序列时优先保留 range；只有当“两个序列要同步”或“消费方必须掌握每一次读取”成为主要需求时，才引入 iter.Pull。这样既保留了 Go 代码的可读性，也不会把 stop 的责任藏在一个不熟悉的适配层里。

常见疑问

next 返回的值在 ok=false 时能使用吗？

不能把它当成有效元素。值的类型零值可能与真实数据相同，是否有效只由 ok 决定。

读到 ok=false 后还必须调用 stop 吗？

读到末尾后通常已经自然结束，但统一使用 defer stop() 更容易覆盖所有路径，也能避免后续修改引入遗漏。

只想提前 break，是否一定要 Pull？

不一定。单个 iter.Seq 用 range 配合 break 就可以；Pull 的价值主要在于把多个序列的读取节奏交给同一个普通循环。

最后可以把这篇文章压缩成一个检查表：先判断是否真的需要逐项拉取；调用 iter.Pull 后保存 next 与 stop；每次读取都检查 ok；任何提前返回都让 defer stop() 负责收尾。