Go iter.Seq 如何把回调迭代接入 range：yield、提前停止与错误传递

把一个分页读取器改成可组合的迭代器时，最容易卡住的不是语法，而是没看清谁拥有“继续”和“停止”的决定权。Go 1.23 的 range 可以直接消费 iter.Seq，但数据库读取、提前 break 和错误返回仍然要由代码明确安排。

yield 返回 false 就表示消费方已经停止；迭代器必须立刻收尾，错误则不能藏在布尔返回值里，应该通过结果值或闭包状态显式带出来。

先把 iter.Seq 的控制权分清

iter.Seq[V] 可以理解为“接收一个 yield 函数，并负责按顺序调用它”。下面的实现故意保留最小状态：生产端只决定读什么，消费端决定要不要继续。

package main

import "iter"

func numbers() iter.Seq[int] {
    return func(yield func(int) bool) bool {
        for n := 1; n 

这里的 range 调用 numbers，numbers 再调用 yield。当循环执行 break，运行时会让当前的 yield 返回 false；因此生产端的 return false 是必要的收尾分支。若忽略这个返回值，分页读取器可能在调用方已经不需要数据时继续读。

把分页读取放进生产端，错误单独走一条路径

实际项目通常不是生成 1 到 5，而是循环读取一页数据。下面用 readItems 表示已有的分页读取函数；它返回当前页和错误。错误不应借用 yield 的 false 来伪装，因为 false 也可能只是正常的提前停止。

func items(readItems func() ([]string, error)) (iter.Seq[string], *error) {
    var err error
    seq := func(yield func(string) bool) bool {
        for {
            page, readErr := readItems()
            if readErr != nil {
                err = readErr
                return false
            }
            if len(page) == 0 {
                return true
            }
            for _, item := range page {
                if !yield(item) {
                    return false
                }
            }
        }
    }
    return seq, &err
}

这个示例把 err 放在迭代器外层，便于调用方在循环后检查。生产端遇到 yield 返回 false 时直接结束；读取失败时先写入 err 再结束，二者的来源不同，排查时不会把“用户只要前两条”和“数据库读取失败”混成一个结果。

提前停止时，资源清理要跟着 stop 走

如果迭代器持有文件、游标或连接，不能只写一个无限循环。可以在迭代器内部用 defer 统一释放资源，并把停止点放在每次 yield 之后。调用方不消费完整序列时，stop 的语义就是“让生产端知道现在该结束”。

一个实用判断是：只要下游可能 break，生产端就必须检查 yield 的布尔结果；只要生产端有错误，就必须保留错误状态，不能在循环后凭空猜测失败原因。

常见问题：iter.Seq 为什么看起来像回调

iter.Seq 和普通 func 有什么区别？

底层确实是函数类型，但 iter.Seq 给出了标准签名，使它可以直接被函数 range 消费，也便于不同迭代器适配器互相组合。

yield 返回 false 时一定是错误吗？

不是。最常见的原因是消费方执行了 break。业务错误应通过独立的 err 或结果结构传递。

为什么不能忽略 stop？

忽略停止信号会让生产端继续读取或计算，文件、游标和网络资源也可能迟迟不能释放。

发布前检查这三个边界

• 确认 Go 版本支持函数 range，并让返回类型使用标准 iter.Seq。
• 确认每次 yield 的返回值都参与停止判断。
• 确认错误状态与停止状态分离，循环结束后有明确的 err 检查。