go中可用goroutine+channel模拟mapreduce分治聚合，适用于单机百万级数据；map阶段并发写入带锁普通map，非sync.map；channel需设合理缓冲防阻塞。
Go 里用 goroutine + channel 模拟 MapReduce，别真拿它跑 PB 数据
MapReduce 在 Go 里没有原生框架，硬套 Hadoop 那套会踩坑。实际能用的，是用 goroutine 分发任务、channel 收集中间结果、再用普通循环做 reduce —— 本质是“分治+聚合”，不是 MapReduce 框架复刻。
适合场景：单机多核处理几万到百万级结构化数据（比如日志行解析、JSON 数组批处理），不是替代 Spark 或 Flink。
- Map 阶段：每个
goroutine处理一个数据分片，输出key-value对到统一chan - Shuffle 阶段：靠
map[string][]interface{}在内存里聚合同 key 的 value，不排序、不落盘 - Reduce 阶段：纯同步遍历 map，调用用户传入的
reduceFunc
为什么不能直接用 sync.Map 做中间结果聚合
sync.Map 看似适合并发写，但它不支持遍历中修改，而 reduce 需要按 key 批量取值；更关键的是，它没有原子性“追加到某个 key 的 slice”能力 —— 你得自己加锁或用 map[string]*sync.Slice（不存在），反而更重。
实操建议：中间结果用普通 map[string][]interface{}，但只在所有 map goroutine 结束后，才开始读写它。用 sync.WaitGroup 控制生命周期：
立即学习“go语言免费学习笔记（深入）”；
var wg sync.WaitGroup
intermediate := make(map[string][]interface{})
mu := sync.RWMutex{}
<p>// map goroutine 内：
mu.Lock()
intermediate[key] = append(intermediate[key], value)
mu.Unlock()注意：append 不是原子操作，必须锁整个 map，别只锁写入那行。
channel 缓冲区设太小会导致 goroutine 卡死
如果用无缓冲 chan 接收 map 输出，而 reduce 端还没启动或处理慢，所有 map goroutine 会在 ch 处永久阻塞 —— <code>WaitGroup 等不到结束，程序 hang 住。
正确做法：
- 给 channel 设缓冲：大小 ≈ 输入数据量 / 并发数 × 2，例如 10 万条数据、开 10 个 goroutine，设
make(chan KV, 2000) - map goroutine 必须用
defer wg.Done()，且放在函数最开头，避免 panic 后漏减计数 - 启动 reduce 前，先
close(ch)，让 range 能退出
reduce 函数里别做耗时 IO 或阻塞调用
reduce 是串行执行的（否则需额外协调 key 分区和并发安全），如果在里面调 http.Get 或写文件，整个流程就退化成“多个 map + 一个慢 reduce”，吞吐卡在最后一步。
常见错误现象：top 显示 CPU 占用率骤降，goroutine 数归零，但程序没退出 —— 正在 reduce 里等网络响应。
解决方式：
- 把 IO 操作提到 map 阶段做（比如预取关联数据），reduce 只做纯计算
- 若必须 IO，改用带超时的
context.WithTimeout包裹，避免单个 key 拖垮全局 - 考虑把 reduce 拆成两步：先聚合出中间状态，再另起 goroutine 批量提交
真正难的不是并发调度，是数据怎么切分才不倾斜、中间结果内存会不会爆、失败后怎么重试 —— 这些没标准答案，得看你的数据分布和 SLA 要求。
