Go slices.Collect 怎么收集迭代器：惰性序列到切片的内存边界

把一段迭代器交给 slices.Collect，代码会从“边生成边处理”变成“一次拿到完整切片”。这个变化很方便，也很容易被忽略：如果上游有几十万条记录，收集动作就会把结果和扩容成本一起带到当前进程里。判断它是否合适，关键不在 API 长不长，而在你能不能接受这次集中分配。

先看清：迭代器和切片解决的是两件事

Go 1.23 引入迭代器后，iter.Seq[T] 可以把“下一个值怎么产生”封装起来。调用方只需要遍历，不必先创建结果数组。例如，从配置表中筛出启用项时，可以让上游逐项产生值：

package main

import (
    "fmt"
    "slices"
)

func enabled(items []string) func(func(string) bool) {
    return func(yield func(string) bool) {
        for _, item := range items {
            if len(item) == 0 {
                continue
            }
            if !yield(item) {
                return
            }
        }
    }
}

func main() {
    got := slices.Collect(enabled([]string{"api", "", "worker"}))
    fmt.Println(got) // [api worker]
}

这里的迭代器本身没有保存 [api worker]。它只在遍历时调用 yield。而 slices.Collect 的职责，是把这些逐个到来的值追加到一个新切片中，返回一个可以按下标访问、传给旧接口的结果。

旧写法的问题：手动追加并没有消失

在 slices.Collect 之前，常见写法是声明一个空切片，再在回调里不断 append。新 API 把这段样板代码收起来了，但底层的容量增长规律仍然存在：

var result []string
forEach(func(item string) bool {
    result = append(result, item)
    return true
})

因此，Collect 不是把迭代器“变成”切片的视图，也不会让结果切片自动共享某个上游数组。它要准备自己的存储空间；上游每产生一个值，就相当于向结果追加一次。小结果集的差异通常不值得手动优化，长列表则需要把内存峰值算进去。

新规则：空结果、长度和容量要分开判断

最容易误判的是空序列。下面的例子没有产生任何元素：

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

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

长度是零，只说明没有收集到数据；它不等于返回值一定是 nil，也不等于后续追加不需要空间。业务接口如果把 nil 和空切片编码成不同 JSON 结果，就要在边界处明确约定，而不是凭经验猜。

同样，len 只表示已经收集了多少项，cap 才能帮助你观察当前底层数组还能容纳多少项。想知道真实成本，建议把收集动作放到基准测试里：

func BenchmarkCollect(b *testing.B) {
    seq := func(yield func(int) bool) {
        for i := 0; i 

执行 go test -bench=Collect -benchmem 后，重点看每次操作的分配次数和分配字节数。这个结果比单独打印一次 cap 更适合比较版本或数据量变化。

代码对比：什么时候直接 Collect，什么时候保留流式消费

如果下游确实需要排序、随机访问或交给一个只接收 []T 的旧接口，直接收集最清楚：

names := slices.Collect(enabled(loadNames()))
slices.Sort(names)
saveAll(names)

但如果只是统计、查找第一个命中项，收集整个结果就是多余的一步。让迭代器在命中后停止，通常更合适：

var found string
enabled(loadNames())(func(name string) bool {
    if name == "worker" {
        found = name
        return false
    }
    return true
})

大数据场景还要加一个明确上限。上限不是为了“让 API 更快”，而是让异常输入不会把进程拖进不可控的扩容过程：

const maxItems = 50000
var result []string
enabled(loadNames())(func(name string) bool {
    if len(result) == maxItems {
        return false
    }
    result = append(result, name)
    return true
})

如果业务不能接受截断，就不要静默停止，应该把“达到上限”变成错误返回或分页请求。这里别急着把所有迭代器都换成 Collect，先问一句：后面的代码真的需要完整切片吗？

兼容注意：版本、类型和提前停止

slices.Collect 属于标准库 slices 包，项目的 go.mod 版本必须和实际使用的语言环境匹配。升级后如果 CI 仍使用旧工具链，问题会在编译阶段出现，而不是运行时才暴露。

另外，回调返回 false 时，上游必须停止继续产生值。自己实现迭代器时，尤其要检查每一个 yield 的返回值；忽略它会让“只找第一个”的调用看起来提前结束，实际上仍然做了后续工作。

可以用一个很小的测试固定这个约定：

func TestIteratorStops(t *testing.T) {
    calls := 0
    seq := func(yield func(int) bool) {
        for i := 0; i 

常见问题：slices.Collect 的几个边界

slices.Collect 会复制元素吗？

它会把迭代器产生的元素放入结果切片。对于字符串、整数等值类型，结果和上游变量之间没有一个可继续追加的共享切片；如果元素本身是指针或包含引用字段，元素内部指向的数据仍按各自类型的语义处理。

空迭代器为什么不等于 nil 切片？

“长度为零”和“切片值为 nil”是两个不同判断。若 JSON、数据库写入或接口响应需要区分两者，应在返回前显式归一化，不要把 len == 0 当成完整判定。

结果很多时，Collect 还能用吗？

可以，但应先确认内存预算，并考虑分页、计数、提前停止或带上限的手动消费。只为找到一个值时，直接遍历通常比先收集全部结果更合适。

如何确认收集动作有没有分配过多？

用 go test -benchmem 观察分配次数和字节数，再用接近生产规模的数据测试。单次运行的 len 或 cap 只能帮助定位，不能代替基准数据。

最后的采用建议

把 slices.Collect 当作“把有限迭代结果物化成切片”的清晰工具：需要排序、下标访问或兼容旧 API 时使用；只需要一次判断或统计时保留流式消费；面对外部输入时加上数量上限和内存预算。这样既能减少回调样板代码，也不会把惰性数据源的风险藏在一个看起来很轻的函数调用里。