slices.Collect 接收惰性序列时的内存预估

slices.Collect 不会因为输入是惰性的 iter.Seq 就自动保持低内存。它会把序列产出的全部值装入一个新切片；当前标准库实现从 nil 切片开始逐项 append，而 iter.Seq 接口本身不提供元素总数。因此，最终占用至少要按“元素数量 × 元素槽位大小”估算，扩容期间还要给旧、新底层数组同时存在留出余量。

官方文档：https://pkg.go.dev/slices#Collect

惰性序列交给 Collect 后还省内存吗

只要开始调用 slices.Collect，答案通常就是“不再流式省内存”。iter.Seq 的惰性体现在元素按需产生，不要求先构造完整输入集合；Collect 的目标却是返回 []E，所以它必须把所有已产出的值保存在结果切片中。

package main

import (
    "fmt"
    "iter"
    "slices"
)

func Even(limit int) iter.Seq[int] {
    return func(yield func(int) bool) {
        // 只有消费者继续请求时才产生下一个偶数
        for n := 0; n 

这个写法适合结果规模小、确实需要随机访问或多次遍历的场景。如果序列可能很长、没有明确上限，或者每个元素还引用大对象，Collect 可能把本来平稳的流式任务变成内存峰值。

从源码看 Collect 为什么无法提前预估容量

Go 1.23 加入了 slices.Collect。当前标准库源码中的核心关系非常直接：Collect 调用 AppendSeq([]E(nil), seq)，AppendSeq 再遍历序列并逐项 append。这里没有长度提示，也没有先扫描一遍。

// 以下是按当前标准库关系缩写的等价说明，不是重新实现标准库
func collectLikeStdlib[E any](seq iter.Seq[E]) []E {
    var out []E
    for value := range seq {
        // 容量不足时由 append 申请更大的底层数组并复制旧元素
        out = append(out, value)
    }
    return out
}

这也解释了为什么不能从 Seq 本身推断准确容量：它只是一个接收 yield 回调的函数类型，可以读取文件、查询数据、动态过滤，也可以没有终点。标准库没有约定 Len()，Collect 只能边接收边增长。

用元素数量和元素类型做保守预算

先把预算拆成三部分：

• 结果底层数组：下限近似为 n × sizeof(E)，实际按最终 cap 和分配器粒度计算。
• 元素引用的载荷：字符串内容、切片底层数组、map、接口动态值和指针对象都不包含在槽位大小里。
• 扩容临时峰值：append 申请新数组并复制时，旧数组可能暂时仍然存活，因此峰值高于最终结果。

不要把某个固定扩容倍数写进容量规划。切片增长策略和内存分配舍入属于运行时实现细节，可能随 Go 版本、元素大小和当前容量变化。可以用 unsafe.Sizeof 在目标架构上查看一个元素槽位的静态宽度，但它不会递归统计引用对象。

package estimate

import "unsafe"

func SlotBytes[E any]() uintptr {
    var zero E
    // 这里只得到切片中一个 E 槽位的宽度，不包含指针指向的数据
    return unsafe.Sizeof(zero)
}

func ArrayLowerBound[E any](count int) uintptr {
    // 这是 len 对应的理论下限，不代表实际 cap、分配器舍入或峰值
    return uintptr(count) * SlotBytes[E]()
}

例如 []string 的切片保存字符串描述符，字符串字节仍在其他内存中；[][]byte 保存内层切片描述符，每个内层底层数组还要另算。Collect 复制的是元素值，不是深拷贝，所以它也可能让这些载荷因结果切片的引用而更久地保持可达。

已知数量时用 AppendSeq 预分配

如果上游同时知道准确数量，就不必从 nil 切片开始。先创建长度为 0、容量为 n 的切片，再交给 slices.AppendSeq。这样仍然消费同一个惰性序列，但常见情况下可以避免中途扩容与复制。

package collect

import (
    "iter"
    "slices"
)

func CollectKnown[E any](seq iter.Seq[E], count int) []E {
    if count 

如果只有上限，也可以把上限作为容量，但要权衡浪费：实际只产出很少元素时，大预留会让底层数组占用过多空间。估计误差很大时，宁可按一个可信的典型批量预留，再让 append 处理超出部分。

数量未知时限制收集边界

数量未知不等于只能盲目 Collect。最简单的办法是给序列增加明确上限，再收集有限结果。

package collect

import (
    "iter"
    "slices"
)

func Take[E any](seq iter.Seq[E], limit int) iter.Seq[E] {
    return func(yield func(E) bool) {
        if limit 

如果结果只会被处理一次，连切片都不必创建，直接 for value := range seq 逐项处理即可。需要批量写入时，可以在消费者侧维护一个固定容量的小批次，满批提交并复用缓冲区；这比把整个数据集 Collect 后再分块更容易控制峰值。

选择 Collect 还是流式消费

Collect 的优势是简单：获得普通切片后，可以随机访问、排序、多次遍历，也能传给只接受 []E 的旧接口。它的代价同样明确：完整物化、容量增长和引用存活时间。

• 结果小且有明确上限：直接 slices.Collect。
• 结果数量已知：预分配后使用 slices.AppendSeq。
• 只处理一次：直接 range 序列。
• 数据量大但要批处理：使用固定大小缓冲区，满批处理后复用。
• 序列可能无限：先截断或加入终止条件，不能直接 Collect。

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

官方文档明确说明，slices.Collect 在序列为空时返回 nil。若调用方必须得到非 nil 空切片，可以在返回后按接口约定转换，或直接使用预先创建的非 nil 目标切片配合 AppendSeq。

Collect 会复制字符串和 map 的全部内容吗？

不会深拷贝。结果切片保存字符串描述符、map 头、指针或接口值等元素槽位，相关载荷仍由这些引用指向。预算时既要算结果槽位，也要算被引用数据及其保活影响。

怎样得到最可信的内存数字？

先用本文模型做上限设计，再在目标 Go 版本、目标架构和真实元素分布上使用基准测试、ReportAllocs 与内存分析工具测量。不要把另一台机器或另一版本观察到的 cap 增长规律当成长期契约。

为什么不先遍历一遍 Seq 计数？

因为 Seq 可能读取外部数据、带副作用、成本高，或者只能自然消费一次。为了计数先跑一遍，再跑第二遍收集，可能让工作重复甚至得到不同结果。数量已知时应由上游显式携带；未知时则应限量或流式处理。

判断重点不在“Seq 是否惰性”，而在“最终是否需要把全部值同时留在内存”。只要答案是需要，就按结果切片、引用载荷和扩容峰值三层预算；如果答案是不需要，就让数据继续停留在迭代器中。