Go slices.Collect 与手写 append：批量转换时如何选择

把 map 中符合条件的值整理成切片时，Go 1.23 之后常会遇到两种写法：用 slices.Collect 接住 iter.Seq，或者自己声明结果切片再循环 append。前者让“遍历并收集”更集中，后者则能直接控制容量和中间状态。选择的关键不在 API 新旧，而在调用方是否需要掌握收集过程。

输入本来就是 iter.Seq，且只需要得到一份结果切片时，优先考虑 slices.Collect；如果要预分配容量、边收集边统计，或需要在中途停止，手写 append 更直白。

先看输入：slices.Collect 接收的是 iter.Seq

slices.Collect 不是“把任意 map 变成切片”的快捷函数，它接收的是 iter.Seq[E]。例如，标准库的 maps.Values 返回值序列，Filter 再把不符合条件的值过滤掉：

func LongStrings(m map[int]string, n int) []string {
    isLong := func(s string) bool {
        return len(s) >= n
    }
    return slices.Collect(Filter(isLong, maps.Values(m)))
}

这里的调用链很明确：maps.Values 提供输入，Filter 决定哪些值继续向下传递，slices.Collect 把通过筛选的值落成新切片。需要注意的是，map 遍历本身没有稳定顺序；如果结果要排序，应在收集后显式调用 slices.Sort 或对应的排序函数。

图 1：maps.Values、Filter、slices.Collect 各自只承担一段转换职责。

只做一次批量转换时，Collect 的表达更紧凑

如果函数的输入和输出都是一次性结果，且没有额外副作用，slices.Collect 往往更容易读。下面的例子把订单表中的状态值筛出，调用方只关心最终的 []string：

func ActiveStatuses(statuses map[int]string) []string {
    active := func(status string) bool {
        return status == "ready" || status == "running"
    }
    return slices.Collect(Filter(active, maps.Values(statuses)))
}

这段写法把“筛选规则”和“收集动作”分开了。以后把输入从 map 换成别的序列，只要仍能提供 iter.Seq[string]，Filter 和 slices.Collect 的主体就不用改。

但它不会替你完成排序、去重、容量预算或错误返回。尤其是序列来自外部数据源时，结果切片的大小仍应在业务层评估。

需要容量和过程控制时，append 更合适

有些转换并不是“遍历完就结束”。例如服务端已经知道最多接收 128 条记录，还要在收集过程中跳过过期记录并计算数量，这时显式循环会更容易审查：

func collectReady(seq iter.Seq[string], capacityHint int) (result []string, skipped int) {
    result = make([]string, 0, capacityHint)
    seq(func(status string) bool {
        if status == "expired" {
            skipped++
            return true
        }
        result = append(result, status)
        return true
    })
    return result, skipped
}

这里有三个业务状态直接写在代码里：seq 提供输入，append 追加有效值，skipped 记录跳过数。make 的容量只是提示，不是结果长度保证；如果实际值超过容量，append 仍会扩容。

图 2：手写收集把 iter.Seq、make、append、result 和 skipped 的关系暴露出来。

Collect 与 append 的选择边界

可以用下面这份小清单做代码评审：

• 只需要结果切片：序列已经准备好，过滤逻辑也能独立表达，选 slices.Collect。
• 需要预分配：有可靠的容量上限，选 make 加 append，但要验证上限是否经常被突破。
• 要统计、记录或提前终止：手写 seq(func(...) bool)，让过程中的状态有明确位置。
• 要稳定顺序：两种写法都不会自动保证 map 顺序，收集完成后再排序。

不要把一次基准测试当成 API 结论

性能比较至少要固定输入规模、保留比例和运行方式。可以先写两个同语义的函数，再用 go test -bench . -benchmem 观察分配和耗时：

func collectWithAppend(seq iter.Seq[int]) []int {
    result := make([]int, 0, 64)
    seq(func(v int) bool {
        if v%2 == 0 {
            result = append(result, v)
        }
        return true
    })
    return result
}

func collectWithCollect(seq iter.Seq[int]) []int {
    return slices.Collect(Filter(func(v int) bool {
        return v%2 == 0
    }, seq))
}

测试时要分别改变序列长度和命中比例，并记录 Go 版本、机器架构、ns/op 与 B/op。如果 capacityHint 只是拍脑袋写的 64，结果并不能代表生产流量；更不能因为一次 benchmark 显示差异，就断言其中一个 API 在所有输入下都更快。

相关问题

slices.Collect 会修改原来的切片吗？

它从序列收集值并返回新切片。是否与输入共享底层数组，取决于序列提供值的方式；不要把“收集结果”当成输入切片的别名来使用。

空的 iter.Seq 收集后是什么？

标准库文档规定空序列的结果是 nil。如果下游必须区分空切片和 nil，要在接口约定中写清楚，或在返回前做统一处理。

map 经过 slices.Collect 后顺序稳定吗？

不稳定。maps.Values 只是提供 map 值的迭代序列；需要稳定输出时，收集后调用排序函数，或从一开始就使用有序输入。

把“简洁”与“可控”分开判断

slices.Collect 适合把一个已经定义好的迭代转换链收束成结果，append 适合把容量、统计和中途决策摊开在代码里。两者不是新旧替代关系：先看调用方需要的是“一个结果”，还是“一个可观察、可干预的过程”，再决定写法，最后用同口径 benchmark 验证真正的成本。