Go slices.Values 如何把切片接入迭代器：空切片、范围与提前停止

有一批已经存在的切片数据，想交给统一的迭代器工具处理时，直接把它复制成另一份切片往往没有必要。Go 1.23 的 slices.Values 可以把 []T 包装成 iter.Seq[T]，让调用方继续使用函数迭代器的接口，同时保留切片按顺序访问、空输入自然结束和消费方提前停止的语义。

slices.Values 是一个惰性的切片适配器：它逐个调用 yield，只有当消费方返回 false 时才停止；它不会因为输入为空而返回特殊错误，也不会自动复制切片。

slices.Values 解决的是哪一层不匹配

普通切片最顺手的写法是 for _, value := range values，但通用库函数经常希望接收一个统一的序列类型。Go 1.23 的 iter 包把这类序列表示为函数类型，iter.Seq[E] 的形态可以理解为“接收一个回调，并按顺序把元素交给它”。

package main

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

func printSeq(seq iter.Seq[string]) {
    for value := range seq {
        fmt.Println(value)
    }
}

func main() {
    values := []string{"Go", "Rust", "Python"}
    printSeq(slices.Values(values))
}

这里没有把 values 转成接口切片，也没有先调用 slices.Collect 生成中间结果。slices.Values 只负责适配，真正什么时候取下一个值，由 for value := range seq 这个消费方决定。

从源码看清 yield 的控制流

理解边界时，最好把实现缩小到三个动作：遍历原切片、调用 yield、根据返回值决定是否退出。Go 标准库的实现就是这个思路，复杂度和普通切片遍历保持在同一个数量级。

func Values[Slice ~[]E, E any](s Slice) iter.Seq[E] {
    return func(yield func(E) bool) {
        for _, v := range s {
            if !yield(v) {
                return
            }
        }
    }
}

Values 调用时只是返回一个函数，直到消费方开始 range，这个函数体才真正运行。每次把元素交给 yield 后，如果回调返回 true，循环继续；返回 false，函数马上 return。所以它不是把切片一次性“推送”到某个隐藏队列里。

这也解释了一个容易忽略的事实：适配器不会复制底层数据。创建 seq 后，如果程序在同一个同步边界内修改了原切片，后续遍历可能读到修改后的元素。需要稳定快照时，应先显式复制，而不是把 slices.Values 当作快照函数。

空切片、空值与结果类型怎么判断

空切片的行为很朴素：for _, v := range s 一次也不进入，因此 yield 不会被调用。下面的通用函数把序列重新收集回来，可以直接验证这个边界。

func collectNames(values []string) []string {
    return slices.Collect(slices.Values(values))
}

func main() {
    empty := collectNames([]string{})
    fmt.Printf("len=%d nil=%v\n", len(empty), empty == nil)
}

对一个非 nil 的空切片调用 slices.Collect，结果是长度为零的切片；它和“没有产生任何元素”是同一件事，不会凭空生成一个业务错误。若调用方区分 nil 与空切片，就应在接口约定中写清楚，并用测试锁定期望。

元素类型也不会在适配过程中被放宽。[]string 产生 iter.Seq[string]，[]User 产生 iter.Seq[User]；它不会自动把不同元素类型合并成一个公共接口。

消费方 break 时为什么能提前停止

函数迭代器最有价值的地方，是消费方可以在找到目标后立即停止。比如只取第一个以 Go 开头的名称：

func firstGo(values []string) (string, bool) {
    for value := range slices.Values(values) {
        if strings.HasPrefix(value, "Go") {
            return value, true
        }
    }
    return "", false
}

当 return 离开 range 循环时，range-over-function 会结束这次消费，内部回调不再接受后续元素。对单纯的 break 也一样：消费方结束后，迭代协议会让 yield false，slices.Values 走到 return，不会继续访问剩余切片。

什么时候用适配器，什么时候直接 range

如果逻辑只服务一个函数，直接 range 切片更直白，调试时也少一层间接调用。slices.Values 更适合下面两种情况：

• 已有通用函数同时接收切片、映射或自定义序列，需要统一成 iter.Seq。
• 希望把过滤、截断、收集等迭代器操作串起来，并让消费方决定是否提前结束。

不要为了“看起来现代”把所有切片都包装一遍。短小的一次性循环，直接 range 的意图更清楚；适配器真正带来的收益，是让数据源和消费逻辑共享同一个序列协议。

常见问题

slices.Values 会复制输入切片吗？

不会。它保存并遍历传入的切片，若需要不受后续修改影响的结果，应先用 slices.Clone 建立快照。

空切片经过 slices.Values 会返回错误吗？

不会。迭代器只是不调用 yield；收集后的结果长度为零，是否为 nil 要按具体输入和接口约定测试。

消费方提前 break 会遍历完整个切片吗？

不会。消费方结束后，yield 返回 false，slices.Values 立即退出，不再访问后续元素。

直接 range 和 slices.Values 哪个更快？

不能脱离场景下结论。一次简单循环优先直接 range；如果要复用统一的 iter.Seq 处理链，适配器减少的是接口转换和中间集合，是否值得应通过实际基准测试确认。

把边界写进测试

这类代码的测试不用复杂，至少覆盖非空顺序、空输入、提前停止和原切片语义四件事。重点不是证明函数“能跑”，而是固定消费协议，避免后续把惰性序列误改成一次性复制。

func TestValuesBoundaries(t *testing.T) {
    got := slices.Collect(slices.Values([]int{2, 4, 6}))
    if !slices.Equal(got, []int{2, 4, 6}) {
        t.Fatalf("got %v", got)
    }

    empty := slices.Collect(slices.Values([]int{}))
    if len(empty) != 0 {
        t.Fatalf("empty len = %d", len(empty))
    }

    count := 0
    for value := range slices.Values([]int{1, 2, 3, 4}) {
        count++
        if value == 2 {
            break
        }
    }
    if count != 2 {
        t.Fatalf("count = %d", count)
    }
}

检查结果应当是顺序保持、空输入没有元素、命中第二个值后只消费两个元素。若业务代码还会跨 goroutine 修改原切片，再增加并发访问测试或在边界处复制数据；迭代器适配本身不会替你处理数据竞争。

总结

slices.Values 的价值不在于替代每一个 for range，而在于用很薄的一层把切片接入 iter.Seq 协议。记住“遍历原切片、逐次调用 yield、收到 false 就退出”这条控制流，空输入、提前停止、结果类型和是否复制等边界就都能推导出来。