iter.seq 不支持并发消费，因其是纯函数值、闭包捕获的变量被多 goroutine 共享导致竞态；需通过 chan 扇出或预分片实现并发。
Go 1.23 的 iter.Seq 本身不支持并发消费，直接在多个 goroutine 中 for range 同一个迭代器会引发竞态或 panic；必须显式分片、扇出（fan-out）或封装为线程安全的生产者。
为什么不能直接对同一个 iter.Seq 并发 for range
Go 编译器为每个 for range 语句自动生成一个独立的 yield 函数调用上下文，但 iter.Seq 是纯函数值，内部状态（如循环变量 i）完全依赖闭包捕获 —— 多个 goroutine 共享同一闭包实例时，i 会被同时读写。这不是“设计限制”，而是语言模型决定的：它本质是 pull-based 的单次可遍历序列，不是可重入资源。
常见错误现象：
- 数值跳变或重复（比如本该输出 0~9，结果出现 0,2,2,4,6,6…）
- goroutine 永久阻塞在
yield()调用里（因闭包状态混乱导致条件判断失效） - 程序 panic：“send on closed channel” 或 “concurrent map read/write”（若 yield 内部用了非线程安全结构）
推荐方案：用 iter.Seq + chan 扇出做并发 Mapper
这是 Go 1.23+ 流水线最实用的组合：用 iter.Seq 做轻量 Source，用带缓冲的 chan 做中间队列，启动 N 个 worker 拉取处理。关键在于让生产端和消费端解耦，避免共享迭代器状态。
实操要点：
- Source 端只在一个 goroutine 中调用
for range seq，逐个send到chan - Channel 容量建议设为
min(1024, N*4)，太小易阻塞，太大浪费内存 - 务必在 Source goroutine 结束后
close(ch)，否则消费者永远阻塞在range ch - 不要用
sync.WaitGroup等待所有 worker，而应让主 goroutinerange ch或用context控制生命周期
示例片段：
func Pipeline[T any](src iter.Seq[T], workers int, fn func(T) error) error {
ch := make(chan T, 1024)
var wg sync.WaitGroup
<pre class="brush:php;toolbar:false;">// 生产端：单 goroutine 驱动 iter.Seq
go func() {
for v := range src {
ch <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper"><img
src="https://img.php.cn/upload/skill/000/000/081/179025319165074.jpg" alt="Golang Spf13 Viper" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper" class="overflowclass">Golang Spf13 Viper</a>
<p class="overflowclass">Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>更高级：预分片 + 无锁并行（适合 CPU 密集型场景）
当数据源可随机访问（如 []T、map 或文件偏移已知），且每个元素处理耗时较长时，绕过 channel、直接分片给 worker 更高效 —— 避免 channel 锁竞争与内存拷贝。
适用条件：
- 输入是切片或可索引结构，能提前知道总长度
- 处理逻辑无共享状态，纯函数式
- worker 数量远小于数据量（否则分片管理开销反超收益）
核心技巧：
- 用
runtime.GOMAXPROCS(0)获取可用逻辑核数作为默认workers - 分片边界计算用
start := i * chunkSize和end := min(start+chunkSize, len(data)) - 每个 worker 自己调用
for j := start; j ，完全无共享
注意：这种模式下你根本不需要 iter.Seq，它只适用于动态/不可索引的数据流（如网络流、数据库 cursor、无限生成器）。
容易被忽略的关键点
真正难的不是启动多个 goroutine，而是控制终止时机和错误传播。比如：
- 某个 worker 处理失败，是否要中断整个流水线？
context.WithCancel是唯一可靠方式 - channel 关闭后，仍有 worker 在
range中 —— 这没问题；但若你在关闭前就return，未启动的 worker 可能漏掉数据 -
iter.Seq内部若含 I/O（如读文件），必须自己加超时或取消，它不感知 context
别指望编译器帮你做并发安全 —— Go 的迭代器是“函数即迭代器”，函数值没有内在同步语义。你写的每行代码，都得自己想清楚谁在读、谁在写、谁负责关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
