Go slices.Collect 如何接住惰性序列：空序列与容量预估边界

分页查询已经改成惰性返回后，最后一步通常还是要交给旧接口一个完整的切片。Go 的 slices.Collect 正好承担这个转换：它接收 iter.Seq，按产生顺序追加元素，空序列则得到一个长度为 0 的切片。真正需要留意的是，空结果的 nil 状态、追加过程和容量预估是三个不同问题。

slices.Collect 适合把一次性消费的 iter.Seq 收集成切片；不要把返回切片的容量当成元素数量，也不要在序列已经消费后期待第二次遍历仍有数据。

先看一个需要完整切片的场景

假设上游分页器逐条产出订单编号，下游导出接口仍然接收 []string。这时不必手写一个临时切片和回调，只要把序列交给 slices.Collect。

package main

import (
    "fmt"
    "slices"
)

func orderIDs() func(func(string) bool) {
    return func(yield func(string) bool) {
        for _, id := range []string{"A-17", "A-18", "A-19"} {
            if !yield(id) {
                return
            }
        }
    }
}

func main() {
    ids := slices.Collect(orderIDs())
    fmt.Printf("len=%d cap=%d ids=%v\n", len(ids), cap(ids), ids)
}

运行结果中的 ids 保持 A-17、A-18、A-19 的顺序。这里的调用链很短：slices.Collect 调用 iter.Seq，序列内部通过 yield 把值交给收集逻辑，收集逻辑再用 append 写入结果切片。

把收集过程拆成三个检查点

检查点一：顺序来自 yield，而不是切片容量

iter.Seq 只是一个接收 yield 函数的函数类型。上游每调用一次 yield，slices.Collect 就有机会按同样的顺序追加一个元素。若上游先做了排序或分页合并，收集结果也只会忠实保留那个已经形成的顺序；Collect 不会自动排序。

工程上可以把“顺序是否正确”放在序列本身的测试里，而不是用 cap(ids) 做推断。容量只回答“当前底层数组能容纳多少”，不回答“元素来自哪里”。

检查点二：空序列先看 len，再决定是否关心 nil

empty := slices.Collect(func(yield func(int) bool) {
    // 没有调用 yield
})

fmt.Println(len(empty) == 0)
fmt.Println(empty == nil)

对空序列，最稳定的业务判断是 len(empty) == 0。如果 JSON 编码、缓存协议或旧接口明确区分 null 和 []，才需要继续验证 nil 语义，并在边界处写出对应测试。不要因为看到长度为 0 就推断底层数组一定已经分配。

检查点三：容量是追加过程的余量

slices.Collect 需要逐步接收元素，内部会围绕 append 构造结果。序列没有提供“最终有多少项”的通用承诺，所以调用方不应把容量当成精确统计值。尤其是分页器、过滤器和提前停止逻辑叠加后，预估数量很容易偏大或偏小。

什么时候应该手写收集逻辑

只要需求是“完整消费序列并得到切片”，slices.Collect 已经足够清楚。下面三种情况才值得手写循环：

• 需要在收集到指定数量后停止，并把停止原因返回给调用方。
• 需要在某个元素出错时保留部分结果，同时携带错误值。
• 能够从可靠的业务元数据得到长度，并且预分配本身已经成为性能瓶颈。

手写时仍然要保留 yield 的提前停止语义：当 append 后发现结果已满足条件，应让上游看到 false 并结束，而不是继续把剩余页面全部拉完。

常见误区与最小验证

最容易出现的误区是用一次收集后的切片做“可重复迭代器”。Collect 得到的是结果，不会替原来的 iter.Seq 增加缓存；如果序列内部连接数据库或读取流，是否能再次调用必须由序列实现决定。另一个误区是为了追求一个好看的 cap 值而提前复制数据，结果反而增加内存峰值。

func collectInts(seq func(func(int) bool)) []int {
    return slices.Collect(seq)
}

func main() {
    got := collectInts(func(yield func(int) bool) {
        for _, n := range []int{2, 4, 6} {
            if !yield(n) {
                return
            }
        }
    })
    if !slices.Equal(got, []int{2, 4, 6}) {
        panic("unexpected order")
    }
}

这段测试只验收业务真正依赖的结果顺序和元素集合；除非协议明确要求，否则不要把某次运行得到的容量写成断言。

相关问题

slices.Collect 会自动去重吗？

不会。它只按序列产生的顺序收集元素，去重需要在上游或收集后显式完成。

空序列应该返回 nil 还是空切片？

先按 len 判断是否为空；只有序列化或接口协议区分两者时，才把 nil 语义纳入测试和转换逻辑。

如何避免收集过多数据？

让 yield 的返回值参与提前停止，或在上游分页器增加明确的上限；不要等完整收集后再丢弃尾部。

小结

slices.Collect 的价值是把惰性序列和传统切片接口接起来。使用时抓住三件事：顺序看 yield，空结果看 len 与协议需求，内存判断看真实数据量而不是某次运行的 cap。这样既能保持代码简洁，也不会把容量、长度和序列生命周期混成一个概念。