Go 1.25 iter.Seq 如何接入流式数据校验：迭代边界与错误回传

如果数据还在网络响应或文件扫描过程中，就先把它们装进切片再校验，内存和延迟都会被一并放大。Go 1.25 继续提供标准库 iter 的 Seq 与 Seq2 类型，可以让生产者按需把值交给 yield，校验失败时立刻停止后续读取。

这类场景适合把校验结果放在迭代函数外部，用 yield 的布尔返回值控制停止；如果需要从推送式迭代器逐个取值，再用 iter.Pull，并在提前结束时调用 stop。

iter.Seq 解决的是哪一段压力

官方定义的 iter.Seq[V] 是 func(yield func(V) bool)。生产者决定什么时候调用 yield，消费者决定是否继续。这个模型适合“读到一条就检查一条”的数据路径，例如逐行检查导入记录、过滤事件或扫描分页结果。

Go 1.25 的发布说明把标准库迭代器作为持续可用的能力；官方 iter 文档还强调，maps.Keys 等标准库 API 可以直接配合范围循环。这里的重点不是把所有切片改成迭代器，而是让上游在下游明确拒绝时停止生产。

先写一个能提前停下来的校验链

下面的例子检查订单编号是否为空。validateOrders 通过返回值把校验错误带到调用方；yield 返回 false 后，生产者不再读取后续记录。

package main

import (
    "errors"
    "fmt"
    "iter"
)

type Order struct {
    ID string
}

func orders() iter.Seq[Order] {
    return func(yield func(Order) bool) {
        for _, order := range []Order{{ID: "A-100"}, {ID: ""}, {ID: "A-102"}} {
            if !yield(order) {
                return
            }
        }
    }
}

func validateOrders(seq iter.Seq[Order]) error {
    var validationErr error
    for order := range seq {
        if order.ID == "" {
            validationErr = errors.New("order ID is empty")
            break
        }
    }
    return validationErr
}

func main() {
    if err := validateOrders(orders()); err != nil {
        fmt.Println(err)
    }
}

运行时会打印 order ID is empty，而 A-102 不会再进入校验。注意这里的业务错误存放在 validationErr，不是由 yield 的 false 自动携带；这正是迭代控制和业务结果需要分开的地方。

为什么不直接返回 error

iter.Seq 的签名没有 error 返回位，它只约定回调是否继续。因此适合把错误写入调用方可见的变量、结果对象，或改用 iter.Seq2[T, error] 明确输出成对值。不要把错误藏在日志里后再让调用方猜测。

需要拉取单个值时，用 Pull 配对 stop

范围循环最自然，但某些解析器需要“取一条、判断一条、必要时暂停”。官方 iter.Pull 把推送式 Seq 转成 next 和 stop 两个函数。只取到前两条就返回时，defer stop() 是释放迭代器执行路径的关键。

func firstValid(seq iter.Seq[Order]) (Order, bool) {
    next, stop := iter.Pull(seq)
    defer stop()

    for {
        order, ok := next()
        if !ok {
            return Order{}, false
        }
        if order.ID != "" {
            return order, true
        }
    }
}

这个函数找到第一条有效订单就返回；stop 让尚未走完的生产函数有机会完成清理。官方文档把这种行为描述为适用于提前停止的消费方，不能省略成“调用过 next 就算结束”。

三个边界决定是否值得改成迭代器

需要重复扫描时

普通 Seq 通常可以被再次调用并重新产生数据，但单次迭代器可能来自不可回退的流。官方文档要求这类 API 明确标注 single-use。若业务要做校验、排序和二次展示，保留切片反而更直观。

需要传递多个错误时

遇到首个坏记录就停，用外部 error 足够；需要收集每条记录的结果，可以设计 iter.Seq2[Order, error] 或返回一个结果对象。不要用全局变量承接并发消费下的错误。

消费者拒绝的时机

yield 返回 false 后，生产者必须立即返回，不能继续调用 yield。官方文档还说明，在回调已经返回 false 后继续调用它会触发 panic，这条约束应在自定义迭代器的测试里覆盖。

落地时保留一条可核对的观察指标

迁移第一版不必做复杂基准。至少记录生产数量、消费数量和提前停止次数：消费数量小于生产总量，才能证明失败确实切断了后续路径；如果两者始终相等，可能只是把切片换成了另一种写法。

建议先在导入校验、分页过滤这类边界清楚的路径试用，保留旧实现做结果对照，再决定是否推广到公共库。公共迭代器的注释要写清元素顺序、是否 single-use，以及调用方提前停止后的清理责任。

常见问题

yield 返回 false 能把 error 一起传出来吗？

不能。它只表达“不要继续生产”，错误需要由调用方变量、结果对象或 Seq2 等接口另行承载。

用了 iter.Pull 还需要 stop 吗？

如果没有自然读到结尾就返回，需要调用 stop；最稳妥的写法是在拿到 next 后立即 defer stop()。

iter.Seq 会自动比切片更省内存吗？

它允许按需产生值，但是否省内存取决于生产者有没有先构造完整数据，以及下游是否真的提前停止，不能只看类型名下结论。

小结

iter.Seq 适合把数据生产和消费连接成一条可停止的路径。先明确错误如何回传，再决定用范围循环还是 iter.Pull；涉及不可回退来源时，把 single-use 和 stop 责任写进接口契约，改造才不会留下隐蔽的资源和重复消费问题。