Go slices.Collect 如何把惰性序列收成切片：空输入与容量预估

接口返回的是一段可以逐项读取的 iter.Seq[int]，而下游旧代码需要一个可以按下标访问的 []int，这时 slices.Collect 正好负责把惰性序列消费成切片。它不会凭空知道元素数量，也不会把同一条序列缓存成可重复读取的数据；空序列最后得到的是非 nil 的空切片，容量是否能提前估计则取决于生产端能不能提供信息。

slices.Collect 的核心动作就是顺序调用 iter.Seq，把每个元素交给内部的 append；先确认序列只消费一次，再决定是否需要自己预分配容量。

先把“惰性序列”和“结果切片”分开

iter.Seq[E] 是一个接收回调的函数类型：生产端在需要时调用回调，把元素一个个送出去。它本身不是切片，没有长度和下标。slices.Collect 需要一个 iter.Seq[E]，内部把收到的值交给 append，最后返回切片。

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

这段代码里，真正发生消费的是 slices.Collect；source() 只是返回生产逻辑。要看清调用链，可以把它记成 iter.Seq -> slices.Collect -> append -> []int。

收集时的停止信号由 yield 返回值决定

通常 slices.Collect 会让生产端把所有元素送完，但序列本身仍然应该尊重 yield 的返回值。下面这个生产函数也可以被其他消费者提前停止；当回调返回 false 时，return 负责结束生产。

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

对 slices.Collect 来说，完整收集时回调会持续返回允许继续的状态，因此三个值都会进入结果。这里不要把 yield 当成普通的“写入函数”：它的布尔返回值是生产端和消费端之间唯一的停止信号。

空输入为什么仍然值得单独验收

如果生产端一次都没有调用 yield，slices.Collect 仍会完成一次收集并返回长度为 0 的切片。调用方可以安全地使用 len(values)，但不能仅凭长度判断序列函数有没有执行过。

empty := func(yield func(int) bool) {}
values := slices.Collect(empty)

fmt.Println(len(values)) // 0
fmt.Println(values == nil) // false

如果接口约定“无结果”和“没有生成结果”是两种状态，就需要在序列外额外携带状态，而不是依靠 slices.Collect 返回的切片区分。收集器只负责元素，不负责业务语义。

容量预估不能靠二次遍历解决

很多人看到批量数据后会先遍历一次算数量，再调用 slices.Collect，但对闭包序列而言这可能重复查询、重复读文件或重复触发分页请求。若生产逻辑有副作用，二次遍历不仅浪费，还可能得到不同结果。

更稳妥的做法是：能从业务边界可靠得到数量时，直接自己创建带容量的切片并消费序列；拿不到数量时，让 append 自己扩容，把可读性和一次消费放在前面。不要为了一个容量数字破坏序列的一次性语义。

把一次收集写成可复查的验收

测试至少覆盖三个结果：完整序列得到预期顺序，空序列长度为 0 且不是 nil，以及元素生产顺序只发生一次。尤其是带计数器的测试，可以及时发现代码为了计算容量而意外重复消费。

func TestCollectOnce(t *testing.T) {
    calls := 0
    seq := func(yield func(int) bool) {
        for _, value := range []int{2, 4, 6} {
            calls++
            if !yield(value) {
                return
            }
        }
    }

    got := slices.Collect(seq)
    if !slices.Equal(got, []int{2, 4, 6}) {
        t.Fatalf("got %v", got)
    }
    if calls != 3 {
        t.Fatalf("calls = %d, want 3", calls)
    }
}

这个断言关注的是可观察行为：元素顺序没有变化，生产端恰好被消费一次。若序列来自网络或数据库，再把分页次数、错误传播和取消信号加入同一组测试。

相关问题

slices.Collect 会返回 nil 切片吗？

空序列收集后是长度为 0 的非 nil 空切片。业务如果明确区分 nil 和 empty，应在收集前后单独维护这层语义。

收集后的切片还能重新遍历吗？

可以。切片已经保存了元素，后续遍历不会再次调用原来的 iter.Seq；但这也意味着收集会把元素全部放入内存。

什么时候不该使用 slices.Collect？

只需要顺序处理、数据量很大或希望尽早停止时，直接消费 iter.Seq 更合适，不必为了得到切片承担完整物化的内存成本。

最后把选择落到数据边界上

需要下标、排序或多次遍历时，用 slices.Collect 把一次性序列物化成切片很直接；只需要边读边处理时，保留 iter.Seq 更省内存。真正需要小心的不是 API 语法，而是序列是否有副作用、空输入是否有业务含义，以及容量预估是否值得额外遍历。