Go slices.Collect 收集迭代器后怎样估算内存成本

估算 slices.Collect 的内存，先用结果切片的 cap × 元素自身大小估计底层数组的元素槽位，再单独考虑字符串、切片和指针引用的数据。这个数既不是完整堆占用，也不是收集峰值：源数据、迭代器状态、扩容旧数组和其他任务可能同时存在。

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

问题现场：记录数固定，为什么收集后内存不只等于记录大小

假设一个任务把一万条记录从迭代器收集为 []Row，想在内存预算里填一个数字。直接用 len 乘几个字段的字节数，容易漏掉容量余量和字段对齐；直接用 unsafe.Sizeof(result)，又只得到切片描述本身。这里采用示例场景推导，没有虚构线上测量数据。

先问两个问题：结果里有多少元素，以及这些元素还引用了什么。前者对应连续槽位，后者决定是否额外保留其他对象。两部分不能混为同一个乘法。

初步判断：先分清切片头、槽位与引用数据

len 表示可访问元素数量，cap 表示该切片可用的容量。对于直接由 Collect 返回、尚未重新切分的普通非零尺寸元素切片，cap 乘元素尺寸可作为槽位的近似预算。分配器取整、元数据和对齐等额外成本尚未算入。

unsafe.Sizeof(Row{}) 包含 Row 自身的字段布局及填充，但不会沿引用递归统计。Name 为 string 时，它包含的是字符串值本身的表示，不是所指向的字符存储；[]byte 字段也是同样道理。若元素为指针，乘法估计的主要是指针槽位，而不是被指向对象。

动手观察：打印容量和元素尺寸，不预设扩容倍率

以下完整程序需要支持 iter.Seq 和 slices.Collect 的 Go 版本，这些 API 自 Go 1.23 提供。示例生成器遵守 yield 返回 false 就停止的约定；名称数据故意使用共享常量，避免把每条记录都误算成独占字符数组。

package main

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

type Row struct {
    ID uint64
    Name string
}

func rows(n int) iter.Seq[Row] {
    return func(yield func(Row) bool) {
        for i := 0; i 

同一元素类型在不同架构下布局可能不同，示例让程序报告实际尺寸。Collect 的 API 没有保证 cap 等于 len，也没有承诺固定的容量增长倍数；因此不要在预算里硬编码“总是两倍”。示例中的数量较小，乘法用于说明概念；对来自外部的巨大计数还应先做范围与溢出检查。

定位原因：最终容量无法代替峰值

Collect 将迭代器值放入新切片，官方实现通过追加收集。迭代器本身不提供通用的长度参数，因此结果可能经历扩容。扩容期间新旧存储可能暂时并存，旧数组何时被回收取决于可达性和垃圾回收进展，最终 cap 无法还原整个过程。

还要看源头。若迭代器包装着一个已存在的大切片，收集结果不会自动释放源切片；若生成器逐项计算且只保留少量状态，则源头成本可能更低。即便使用了迭代器，Collect 仍然会物化全部结果，不能把“迭代器输入”理解为“结果常量内存”。

引用数据也不能机械求和。多条 string 可能共享相同内容，同一个对象也可能被多个指针引用；相反，一个很短的子串可能让更大的原始存储继续可达。估算独占内存时，应按实际对象及共享关系去重，而不是只累加表面长度。

修复方案：已知数量预分配，只需汇总则不收集

不要为了获得长度而无条件遍历两次。部分迭代器只能消费一次，或包含读取外部资源、改变状态等行为；重复消费可能没有相同结果。预分配也不能限制最终数量，来源超出容量时追加仍会增长。

slices.Clip 只是限制切片可见容量，并不会重新分配一个更小数组。因此不能在 Clip 后用新的 cap 乘元素尺寸，宣称原来的大数组已经释放。需要独立的小存储时，应明确创建并复制，再确认旧引用不再需要；复制本身也会提高暂时占用。

观察结果：用同一个指标回答同一个问题

槽位估计、累计分配字节、存活堆内存和进程驻留内存是不同指标。应先决定预算关注长期保存还是收集瞬间峰值，再在真实环境下观察。本文没有执行程序或给出某次收集的实测容量与峰值。

Collect 会深复制字符串或指针对象吗？

不能把它当深复制工具。收集的是元素值，元素内部的引用仍可能共享数据。

空迭代器会得到非 nil 空切片吗？

官方契约规定 Collect 在序列为空时返回 nil。它没有元素槽位，但外围调用和生成器的成本要另看。

预分配越大越好吗？

不是。只应按可信数量或有边界的估计分配，并把未使用容量也计入预算。

参考：Collect 与 AppendSeq 契约；切片迭代器收集实现；Sizeof 的统计范围；Clip 的容量语义。