Go 语言的迭代器（iter 包）推出已有一段时间，然而，无论是身边的朋友还是网上的技术讨论，负面意见似乎都占据了主流。最集中的观点是：这东西用起来太凌乱、太不直观，完全不符合 Go 简单直白的风格。坦白讲，初次接触 iter.Seq, iter.Pull 等定义时，我感觉大多数人应该都会有一种不知所云的陌生感。
这种困惑源于我们对迭代器的先入为主：迭代器应该包含一个 Next() bool 方法，比如标准库中的 sql.Rows，通过调用 Next 方法来完成迭代。然而，当我们看到 Go 实际提供的 iter.Seq------一个函数嵌套函数的类型定义时，很容易直接望而却步，丧失深入了解的兴趣。我当初看到 Pull 函数时，甚至怀疑是否看错了目录，迭代与"拉取"有何关联？
但随着开源社区，尤其是涉及分块或流式返回的库，开始积极采纳 iter 方案，我们必须认识到拥抱标准库的必要性。统一的代码风格、未来可能的语法工具支持，都促使我们去理解其背后的设计哲学。因此，本文旨在深入探讨：为什么 Go 的迭代器看起来如此"怪异"？又是什么原因让 Go 选择了这种设计？
为什么 iter 包看起来如此陌生？
这个问题归根结底，是因为 Go 的迭代器选择的是推模式（Push Mode / Internal Iteration），而非我们习惯的拉模式（Pull Mode / External Iteration）。
习惯的拉模式（Pull Mode）
拉模式的典型特征是：消费者主动发起循环，并通过调用 Next() 方法，从迭代器中拉取下一个元素。 控制权在外部调用方。
示例：Go 标准库 database/sql
go
func QueryUsers(db *sql.DB) ([]User, error) {
// ...
defer rows.Close()
// 开发者主动编写循环，主动调用 Next() 拉取数据
for rows.Next() {
// ...
}
// ...
}其他语言提供的迭代器也多数为拉模式为主，
如 java:
java
Iterator<String> it = list.iterator();
while (it.hasNext()) {
String s = it.next();
System.out.println(s);
}如 rust:
rust
let v = vec![1, 2, 3];
let mut iter = v.iter();
// 显式拉取
assert_eq!(iter.next(), Some(&1));
assert_eq!(iter.next(), Some(&2));
// 语法糖 for 循环本质上在不断调用 next()
for val in v.iter() {
println!("{}", val);
}如 python:
python
def my_gen():
yield 1
yield 2
g = my_gen()
print(next(g))
print(next(g))无论是 Java 的 Iterator、Rust 的 Iterator trait，还是 Python 的 next() 函数，其核心思想皆是如此：开发者主动发起循环，并通过 next() 函数获取下一个元素，掌控着步进的速度与时机。这种模型非常直观，因为它与我们日常的命令式编程思维相一致。
Go 的推模式（Push Mode）
推模式的核心在于控制权反转 ：循环和迭代逻辑被封装在迭代器内部。迭代器主动发起循环，每次迭代到当前元素时，通过我们注入的 yield 回调函数，将迭代到的元素"推"给我们。我们是被动接收数据，而非主动拉取。
iter 包的核心定义正是推模式的体现：
go
type Seq[V any] func(yield func(V) bool)
type Seq2[K, V any] func(yield func(K, V) bool)迭代器本质上是一个高阶函数，其参数 yield 是一个回调函数，用于接收被推送的元素，并返回一个布尔值，告知迭代器是否继续（true 为继续迭代，false 为终止迭代）。
推迭代器的实现
还是以 sql.Rows 为例，将其封装为推迭代器：
go
func ScanUsers(rows *sql.Rows) iter.Seq2[User, error] {
return func(yield func(User, error) bool) {
// 资源清理（defer）由迭代器内部保证执行
defer rows.Close()
// 循环和迭代逻辑由迭代器内部驱动
for rows.Next() {
// ... Scan 逻辑，将 User 变量赋值给回调函数
if !yield(u, nil) {
return // 接收到外部停止信号，优雅退出，触发 defer
}
}
}
}推迭代器的消费与语法糖
最原始的消费方式是直接调用返回的函数，并传入回调：
go
users := ScanUsers(nil)
users(func(user User, err error) bool {
// 接收推送的元素
if err != nil {
// ... 打印错误
return false // 返回 false 告知迭代器停止
}
// ... 正常处理
return true // 返回 true 告知迭代器继续
})这种方式很好理解，也很直白，不过 Go 也提供了迭代器的语法糖，使用 for-range 完成迭代器的遍历：
go
users := ScanUsers(nil)
for user, err := range users { // 统一的遍历方式
if err != nil {
// ... 打印错误
break // break 相当于 yield 回调返回 false
}
// ...
}这种 for-range 语法糖，其实和直接调用 users 函数是一致的，break 就相当于 yield 回调返回了false，但坦白讲这个语法糖有些过于隐式了，如果开发者初见 iter.Seq2，然后尝试使用 for-range 完成迭代，估计没多少人能联想到底层发生了什么，这和 Go 一贯的简单、直观的风格是有些相违背的。但也得承认，习惯之后使用 for-range 遍历迭代器确实很简单，而且迭代方式和其他容器类型（切片、Map、数组等）保持了高度的一致性，用习惯了确实还是比直接手动调用迭代器函数的方式更加优雅便捷。
为什么 Go 坚持选择推模式？
排除对拉模式的先入为主，客观对比会发现推模式除了有些隐式之外，确实具有一系列的工程优势。Go 团队的选择，是基于性能、安全、以及 Go 自身语言特性的深思熟虑。
性能维度：零成本抽象与逃逸分析
极度有利于内联优化（Inlining） ：推迭代器是高阶函数，Go 编译器擅长内联闭包。这使得 for-range 一个迭代器在编译后，几乎等同于手写内联循环。这消除了拉模式中可能存在的接口方法调用开销。
避免堆内存分配与 GC 压力 ：拉模式迭代器通常需要一个结构体来维护状态（如当前索引、树的栈）。如果该结构体逃逸到堆上，会增加 GC 负担。推模式的状态（如循环变量 i 或连接句柄）则被封装在闭包的栈帧中，极大地方便了编译器的逃逸分析（Escape Analysis），实现了高性能的零成本抽象。
资源安全维度：确定性的资源清理
这是推模式最重要的优势之一，特别是对于 I/O 密集型的后端程序（如 DB、文件流）。
拉模式的风险 ：资源清理（如 rows.Close()）依赖于外部调用者。如果调用者在循环中提前 break 或发生 panic，而忘记了 defer 或处理不当，极易导致连接泄漏。
推模式的保障 ：defer rows.Close() 位于迭代器内部。无论外部是正常遍历结束，还是中途通过 yield 返回 false 来终止，迭代器函数都将退出，从而确定性地触发 defer 语句。这从语言层面保证了资源的可靠释放。
实现维度：简化复杂结构的遍历
对于复杂的树或图结构，实现拉模式的 Next() 方法需要手动编写一个复杂的状态机来保存遍历路径栈。而推模式则可以直接利用 Go 函数的递归调用栈，让迭代器代码的编写变得简单且直观。
iter.Pull 与 iter.Pull2 的作用
现在看到 pull 这个单词应该就能明白其含义了，就是拉模式的意思，因为 iter 包提供的迭代器都是推模式的迭代器，但有些场景下必须使用拉模式的迭代器，故这两个函数的作用就是将推模式的迭代器 转化为拉模式的迭代器，代码如下：
go
func main() {
arr := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
// 此处将切片转化为一个推模式迭代器
arrSeq := slices.All(arr)
for i, v := range arrSeq {
fmt.Println(i, v)
}
// 将推模式迭代器转化为拉模式迭代器
next, stop := iter.Pull2(arrSeq)
defer stop()
for {
i, v, ok := next()
if !ok {
break
}
fmt.Println(i, v)
}
}此处分别用推拉两种迭代器遍历了整个切片，输出的结果是完全一致的，拉模式的迭代器确实看起来更熟悉，调用 next() 函数即可获取下一个切片的索引和值，ok 变量为 false 时则表明无法再进行迭代了。
这里看着有点难以理解的是 stop，这是因为拉模式迭代器本质上是包装了的推模式迭代器，我们需要具备让推迭代器停下来的能力，也就是让推迭代器的 yield 参数返回 false，这个 stop 函数在调用时就会起到这个作用，让推迭代器停下来，否则迭代器并不会停止，而是一直等着 next 函数被调用。另外，stop 函数应该确保最终一定被执行，因为拉模式的迭代器内部会单独启动一个协程，只有调用了 stop 函数 ，迭代器被停止，才能释放这个协程，故不调用 stop 函数会导致协程泄露，一定要记得调用。
那为什么 Go 在提供了推模式迭代器的同时，一定要也提供个拉模式的迭代器呢？因为推模式迭代器整个迭代的过程外部是无法控制的 ，我们只能通过 yield 回调被动接收当前迭代的元素，无法控制迭代的进度或速度，只有改成拉模式，才能通过改变调用 next 函数的时机，从而对迭代过程做出精细化的控制。
总结
Go 迭代器初看起来的"怪异"，源于它选择了反直觉的推模式。但这并非故弄玄虚，而是 Go 团队在性能优化、资源安全（尤其是 defer 机制的整合）和语言简洁性之间取得的平衡。
虽然 for-range 语法糖初看隐式，但一旦理解了其背后的推模式哲学，我们便能体会到它带来的便利与可靠性。随着越来越多的标准库和三方库开始采用 iter 规范，我们也应积极拥抱，让这种高效且安全的迭代模式成为 Go 编程的新常态。