Go iter.Pull 提前停止怎么收尾：yield 生命周期、defer 清理与测试边界

把 Go 的 iter.Seq 接到分页读取、树遍历或过滤器时，iter.Pull 很方便：调用方拿到 next，一次取一个值。但如果只取到一半就返回，后台的 yield 还可能停在等待下一次接收的位置。这个场景的关键不是“多调用一次函数”，而是把迭代器的结束责任交给明确的 stop。

iter.Pull 改变的是消费方式，不是结束责任

标准迭代器是 push-style：生产方调用 yield(v)，由 yield 的返回值决定是否继续。iter.Pull 把它包装成 pull-style，消费者通过 next() 主动取得下一个值，同时获得一个用于结束迭代的 stop()。

func firstMatch(seq iter.Seq[string], want string) (string, bool) {
    next, stop := iter.Pull(seq)
    defer stop()

    for {
        value, ok := next()
        if !ok {
            return "", false
        }
        if value == want {
            return value, true
        }
    }
}

这里有两个正常出口。完整消费时，next 返回 ok == false；提前命中时，函数直接返回，由 defer stop() 补上迭代器收尾。把这两条路径都交给同一个清理动作，后续修改循环也不容易漏掉结束逻辑。

为什么提前 return 仍需要 stop

下面的序列故意在 yield 返回后继续做清理，并记录它是否已经离开：

func tracked(values []string, closed *bool) iter.Seq[string] {
    return func(yield func(string) bool) {
        defer func() { *closed = true }()
        for _, value := range values {
            if !yield(value) {
                return
            }
        }
    }
}

消费者取到第一个值后就不再调用 next。如果没有 stop，生产方的生命周期不会按照调用方的意图完成；有了 defer stop()，yield 会收到停止信号，序列函数才有机会执行自己的 defer。这类清理可以是文件、游标、临时位置或内部 goroutine 的退出动作。

完整消费和提前停止的边界不同

当 next 已经返回 false，序列自然结束，之后调用 stop 仍然是合法的。官方示例仍建议统一使用 defer stop()，原因是调用方不必在每个分支上判断自己究竟是自然结束还是提前返回。

别把 next 和 stop 分给不同 goroutine

iter.Pull 的这对函数不是一个可以随意并发共享的队列 API。官方契约明确禁止多个 goroutine 同时调用 next 或 stop。如果业务需要并发处理，应先由一个 goroutine 顺序拉取，再把已经取出的值发送给工作队列；不要让多个消费者直接争用同一个 next。

func collectTwo(seq iter.Seq[int]) []int {
    next, stop := iter.Pull(seq)
    defer stop()

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

这个例子只让当前函数拥有拉取器，返回后由 defer 负责停止。若要把结果交给并行任务，先把 result 或受控通道交给其他 goroutine，生命周期边界会清楚很多。

测试要验证清理，而不是只验证取到了几个值

针对提前停止，测试至少应同时检查业务结果和序列是否已经退出。一个简单的测试替身可以在退出时关闭通道，消费者只取第一个值，然后等待这个可观察状态。

func TestFirstMatchStopsSequence(t *testing.T) {
    closed := make(chan struct{})
    seq := func(yield func(int) bool) {
        defer close(closed)
        yield(7)
        yield(9)
    }

    next, stop := iter.Pull(seq)
    value, ok := next()
    if !ok || value != 7 {
        t.Fatalf("first value = %v, %v", value, ok)
    }
    stop()

    select {
    case 

生产测试中仍建议写成 defer stop()，上面的显式调用只是为了把停止点展示出来。还可以补测三件事：自然耗尽后再次调用 next、重复调用 stop，以及序列函数 panic 时错误是否按契约传播。不要用固定 sleep 判断收尾，使用通道、WaitGroup 或其他明确的完成信号。

迁移旧式手写拉取器时先对照三件事

如果项目里原本有一个 channel 加后台 goroutine 的拉取器，迁移到 iter.Pull 不应只替换函数名。先检查生产方何时结束、消费者如何表达不再需要、清理动作由谁负责。stop 解决的是迭代器生命周期，不会替你完成业务取消、超时或跨 goroutine 的同步。

• 旧实现通过关闭通道结束时，确认新序列的 defer 在 stop 后确实执行。
• 旧实现允许多个消费者时，先收敛为单一拉取方，再把结果分发出去。
• 旧实现靠 context 取消时，继续保留 context；不要把 stop 误当成业务取消信号。

相关问题

只调用 next 到 false，还需要 stop 吗？

自然耗尽后重复调用 stop 是合法的。工程上仍建议统一注册 defer stop()，这样提前返回和自然结束使用同一条清理路径。

stop 可以调用多次吗？

可以。它允许重复调用，也允许在 next 已返回 false 后调用。

next 能放到多个 goroutine 里吗？

不能把同一个拉取器当成并发安全队列。next 和 stop 不应被多个 goroutine 同时调用，应该由一个顺序消费者持有。

stop 会自动取消整个业务请求吗？

不会。它结束的是迭代器消费关系；网络请求、数据库查询或后台任务仍需使用各自的 context、关闭接口或同步机制。

最小验收清单

• 拿到 next 和 stop 后是否立即注册了 defer stop()。
• 提前命中、自然耗尽、错误返回三条路径是否都能让序列函数退出。
• 是否只由一个消费者调用 next 和 stop。
• 测试是否用明确完成信号验证清理，而不是依赖等待时间。