用 slices.Collect 接收惰性迭代结果

我第一次把 slices.Chunk 接到批量写入逻辑时，最容易混淆的是“拿到了一组结果”和“拿到了一组已经物化的切片”。前者只是 iter.Seq[[]T]，真正需要保存、索引或交给下一层时，再用 slices.Collect 接收它。这个组合能把惰性遍历和明确的数据边界分开。

记住一条判断：slices.Collect(seq) 会新建一个结果切片；空序列得到 nil，而 slices.Chunk 的每个批次仍然是源切片的子切片。是否需要复制，取决于后续代码是否要独立持有数据。

slices.Chunk 产生的惰性分块如何被接收

Chunk 的函数签名是 func Chunk(s, n) iter.Seq[Slice]。它描述“怎样逐个提供批次”，并没有先创建一个完整的二维切片。Collect 的作用就是在这个边界上消费序列，把每次产出的元素追加到新切片中。

package main

import (
    "fmt"
    "slices"
)

type Record struct {
    ID    int
    Value string
}

func main() {
    records := []Record{{1, "A"}, {2, "B"}, {3, "C"}, {4, "D"}, {5, "E"}}

    // Chunk 只描述批次序列；Collect 在这里把序列接收为 [][]Record。
    batches := slices.Collect(slices.Chunk(records, 2))
    for i, batch := range batches {
        // 每个批次最多两个元素，最后一批允许不足两个。
        fmt.Printf("batch %d: %v\n", i+1, batch)
    }
}

这里的 batches 类型是 [][]Record。它适合需要先统计批次数、按下标选择一批，或把批次交给另一个同步函数的场景。若只是顺序处理一次，直接 for batch := range slices.Chunk(records, 2) 更省内存，不必先 Collect。

Collect 的返回值语义要先写进边界条件

slices.Collect 对非空序列返回一个新切片，对空序列返回 nil。因此，判断“有没有元素”用 len(result) == 0 最稳妥；只有在接口协议明确区分 JSON 的 null 和 [] 时，才需要额外处理 nil。

// collectNonEmpty 只保留非空文本，并保留 nil 与非 nil 的含义。
func collectNonEmpty(values []string) []string {
    seq := func(yield func(string) bool) {
        for _, value := range values {
            if value == "" {
                continue // 空值不进入结果序列。
            }
            if !yield(value) {
                return // 下游提前停止时，不再继续生产数据。
            }
        }
    }
    return slices.Collect(seq)
}

另一个容易漏掉的点是所有权。Chunk 给出的是源切片的连续子切片，适合在当前调用期间读取；如果批次要放入异步队列，或源切片之后还会被复用和修改，就应该复制。

批次需要独立生命周期时再复制

复制不是 Collect 的默认职责。可以先接收批次，再对要长期保存的批次做 slices.Clone，把“序列物化”和“数据所有权”拆成两个明确动作。

// ownedBatches 为每个批次建立独立的底层数组，便于跨 goroutine 或队列保存。
func ownedBatches(records []Record, size int) [][]Record {
    collected := slices.Collect(slices.Chunk(records, size))
    owned := make([][]Record, 0, len(collected))
    for _, batch := range collected {
        owned = append(owned, slices.Clone(batch)) // Clone 只复制当前批次元素。
    }
    return owned
}

生产代码还要约束 size。slices.Chunk 在批大小小于 1 时会 panic；空源切片不会产生一个“空批次”，所以返回的批次集合是 nil。把参数校验放在业务入口，错误会比深层 panic 更容易定位。

常见问题

slices.Collect 能把任意函数结果变成切片吗？

不能。输入必须是 iter.Seq[T]，也就是接收 yield func(T) bool 的迭代函数；普通返回值需要先转换成这个序列形状。

为什么不直接一直使用 iter.Seq？

一次性消费、可以流式处理时直接 range 更合适；需要复用、索引、统计长度或跨层传递时，Collect 才提供明确的物化边界。

Collect 会把 Chunk 的元素深复制吗？

不会。Collect 新建的是外层结果切片，Chunk 中的元素仍可能来自源切片；需要独立批次时，对每个批次调用 slices.Clone。

我的取舍是：能边遍历边处理，就保留惰性序列；只有业务确实需要“接收结果”时才 Collect，再根据生命周期决定是否 Clone。这样既不会无意中提前物化全部数据，也不会把底层数组共享问题留到异步流程里。