iter.Pull 未关闭造成 goroutine 残留的定位

先给结论：iter.Pull 返回的不是一个可以“用完不管”的函数，而是一对 next 和 stop。只要调用方可能在序列结束前返回，就应在拿到它们后立刻 defer stop()。否则底层 push iterator 可能仍卡在等待下一次消费的 goroutine 上，重复调用后就会看到 goroutine 数量持续增加。

iter.Pull 为什么会留下 goroutine

Go 1.23 的 iter 把 push iterator 转成 pull iterator。push iterator 通过 yield 推送值，next 每次取一个值；当调用方不再需要后，stop 负责让底层迭代器停止。官方示例也采用“获得 stop 后立即 defer”的写法。

第一处定位：是否在读完前提前退出

最容易漏掉清理的是比较、过滤和限量读取：遇到第一个不相等值就返回，或只取前几个值就结束。把 defer stop() 放在获得迭代器的同一段代码里，可以覆盖这些分支。

func firstMatch[V comparable](seq iter.Seq[V], want V) bool {
	next, stop := iter.Pull(seq)
	defer stop() // 提前返回时通知底层 yield 停止，避免资源残留

	v, ok := next()
	if !ok {
		return false // 序列为空，stop 仍保持调用路径一致
	}
	return v == want // 比较失败也会经过 defer stop
}

如果代码只写了 next, _ := iter.Pull(seq)，或者把 stop 放在某个成功分支里，失败分支就可能绕过清理。这里的“关闭”不是关闭文件，而是结束由 pull 转换层维护的迭代关系。

第二处定位：是否把 next 和 stop 并发调用

iter.Pull 的一对函数不是并发安全队列。官方文档明确规定，不能让多个 goroutine 同时调用 next 或 stop。若业务需要并发处理，应由一个 goroutine 串行拉取，再把值发送给下游，而不是让多个消费者共享同一个 next。

第三处定位：用证据区分残留和正常波动

排查时记录三件事：是否收到 ok=false、每个退出点是否经过 stop、重复执行后 goroutine 数量是否回到近似基线。可以在测试或诊断代码中观察趋势：

before := runtime.NumGoroutine()
for i := 0; i 

若数量短暂上升后回落，可能只是调度尚未完成；若每轮都增加且没有回落，再回到退出路径检查 stop 是否遗漏。这个观测只帮助定位，不替代对代码生命周期的判断。

修复后的最小清单

1. 每次调用 iter.Pull 都保存 stop，并紧邻调用 defer stop()。
2. 检查所有 return、比较失败和 panic 路径是否仍在同一函数栈内。
3. 不要把同一个 next 或 stop 分发给多个 goroutine。
4. 重复执行代表性场景，结合 goroutine 趋势和代码路径复核结果。

常见问题

读到 ok=false 后还要调用 stop 吗？

严格来说序列已结束时通常不再需要，但统一使用 defer stop() 更不容易漏掉提前返回路径。

为什么只增加一次 stop 仍然有残留？

检查是否存在多个 Pull 实例、某些分支没有建立 defer，或是否把同一实例跨 goroutine 使用。

能用 GC 自动回收解决吗？

不能把 GC 当作协作式停止信号。先让 pull iterator 收到 stop，再观察 goroutine 是否退出。