Go iter.Pull 提前停止遍历时为什么要调用 stop

iter.Pull 把推送式迭代器转换成 next 和 stop 两个函数。消费者只取部分值就退出时，源迭代器可能仍停在交付当前值的位置；调用 stop 才能让它结束并返回，使其中的 defer 等清理逻辑有机会执行。通常在 Pull 之后立即写 defer stop()，避免命中条件、错误返回等分支漏掉停止责任。

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

使用场景：找到目标后，不想再取后面的值

假设一个扫描函数只需要找到第一个符合条件的数字。直接 range 可以在命中时返回；改成 Pull 后，代码可能拿到一个值就 return，却没有考虑提供这个值的迭代器是否已经退出。消费者函数返回和源迭代器返回，是两个不同的生命周期事件。

这类问题不一定首先表现为内容错误。结果可能已经正确，但源迭代器的清理标记尚未更新，或者它持有的资源还没有按约定释放。因此判断代码是否完整，不能只看“找到了正确元素”，还要看停止责任由谁承担。

候选方案：直接 range，还是手动调用 next

如果消费过程就是一个顺序循环，优先考虑直接 range。它让“取值、处理、提前结束”出现在一个清楚的语法范围内，不需要业务再持有停止函数。Pull 更适合消费端需要显式控制何时取下一个值的情况，例如在一个有限的局部算法中穿插多次取值。

// 直接顺序查找时，range 更容易表达退出位置。
func FirstMatch(seq iter.Seq[int], accept func(int) bool) (int, bool) {
    for value := range seq {
        if accept(value) {
            return value, true
        }
    }
    return 0, false
}

如果选择 Pull，就把 next 和 stop 视为同一次消费会话的一对接口。next 负责请求值；stop 负责声明不再需要后续值。只把 next 保存下来而丢弃 stop，会让会话缺少一个明确的提前结束入口。

对比维度：结果可用，不等于会话已结束

这里的耗尽不是“我觉得最后一个值已经取到了”。只要 next 尚未给出结束信号，调用方决定停止时就应履行 stop 责任。不要为了触发清理而把剩余序列全部读完：后面可能还有大量工作，甚至根本没有有限终点。

推荐选择：Pull 后立即安排 defer stop

下面的完整示例用清理标记表达生命周期，不涉及文件、网络或自定义并发实现。序列在真正退出时设置 cleaned，消费端在遇到阈值后提前返回。该示例可供读者自行运行，本文未执行本地代码，不提供虚构输出。

package main

import (
    "fmt"
    "iter"
)

func sample(cleaned *bool) iter.Seq[int] {
    return func(yield func(int) bool) {
        // 只有迭代器退出时，清理标记才会更新。
        defer func() { *cleaned = true }()
        for _, value := range []int{3, 8, 13, 21} {
            if !yield(value) {
                return
            }
        }
    }
}

func firstAbove(seq iter.Seq[int], limit int) (int, bool) {
    next, stop := iter.Pull(seq)
    // 紧接 Pull 安排收尾，覆盖命中、耗尽和后续新增的返回分支。
    defer stop()

    for {
        value, ok := next()
        if !ok {
            return 0, false
        }
        if value > limit {
            return value, true
        }
    }
}

func main() {
    cleaned := false
    value, ok := firstAbove(sample(&cleaned), 10)
    // 这里读取标记，是为了展示消费函数已完成停止责任。
    fmt.Println(value, ok, cleaned)
}

按代码约定，命中的值应为 13，返回状态为 true，消费函数返回后 cleaned 应为 true。清理标记的含义仅限这个示例：它不是资源监控器，也不能代表其他外部任务的退出状态。

defer 的位置同样重要。若在一个很长的函数中反复创建 Pull 会话，所有 defer 都可能拖到外层函数返回才执行。可把每次消费收进一个小函数，或在本轮完成后显式 stop，并保留清楚的兜底责任。不要机械地把 defer 放进循环后就认为清理及时性已经解决。

不适用情况：stop 不是任意外部工作的取消器

stop 结束的是适配后的迭代会话，不应被当作通用 context 取消机制。若源迭代器自己调用其他阻塞操作，组件仍需要符合自身接口约定的退出设计。本文只讨论 Pull 的消费协议，不承诺它能中断所有外部 I/O。

源迭代器也必须遵守 yield 的返回值。收到 false 后应停止继续产出并返回，否则问题出在源函数协议实现。调用 stop 不能成为源迭代器忽略停止约定的补丁。

自然结束后再调用 stop 是允许的，因此统一 defer stop 的写法不需要额外维护“是否耗尽”的布尔状态。多维护一个标记会增加分支，未必带来实际收益。停止也不是重置：同一对 next、stop 不能通过再次调用 stop 恢复到序列开头。

决策表：按消费范围选择写法

如果一个接口返回 next 给其他组件，却把 stop 留在已经结束的构造函数里，生命周期就可能错位：过早停止会让下游拿不到值，不安排停止又会遗失责任。更稳妥的接口应把消费与关闭能力成对交付，并在文档中说明拥有者。

常见问题

next 已经返回 false，还必须单独再调用 stop 吗？此时序列已经结束，仍允许调用 stop。统一 defer 写法可以覆盖所有出口。

stop 可以重复调用吗？可以，但这不代表能从多个 goroutine 同时调用 next 或 stop；接口不允许这种同时调用方式。

只取一个值时也需要吗？只要没有通过 next 的结束信号确认耗尽，就应在不再需要后续值时停止，消费数量少不会自动免除责任。

把 stop 设置成 nil，是否有同样效果？没有。丢弃函数值只是让调用方失去停止入口，不会替你执行它。

Pull 的便利来自消费端可以主动决定取值时机，相应地也要明确结束时机。把 stop 与会话作用域绑定，再判断是否真的需要手动拉取，代码会更容易维护。

参考：Go 官方 Pull 接口与停止约定；Go 官方迭代器协议说明。