Go中无内置MapReduce框架，需用goroutine+channel模拟分治流程：拆数据→并行map→合并reduce，适用于单机多核场景，关键在控制并发粒度、channel缓冲与错误恢复。
MapReduce 在 Go 里不是内置模型，别直接找 mapreduce 包
Go 标准库没有 MapReduce 抽象类型或框架——它不提供类似 Hadoop 或 Spark 那样的分布式运行时。你看到的所谓“Go 实现 MapReduce”，本质是用 goroutine + channel 模拟分治流程，适用于单机多核场景，而非集群调度。如果目标是处理 TB 级日志或跨节点聚合，得换工具；如果只是想压满 CPU 跑一批 JSON 日志统计词频，Go 完全能胜任，但得自己搭骨架。
用 sync.WaitGroup + chan 实现最简可行版
核心逻辑就三步：拆数据 → 并行 map → 合并 reduce。关键不是套概念，而是控制并发粒度和 channel 容量，否则容易卡死或 OOM。
-
map阶段：把输入切片按 chunk 分发给多个 goroutine，每个返回[]KeyValue（type KeyValue struct { Key string; Value int }） -
reduce阶段：用map[string]int合并所有 key 的 value，注意加锁或用sync.Map（仅当 key 写入频繁且读多写少时才值得） - 别用无缓冲 channel 做中间传输——大量小结果会阻塞 sender；建议带缓冲：
make(chan []KeyValue, runtime.NumCPU()) - 示例中常见错误：忘记
close(ch)导致range ch永不退出；或WaitGroup.Add()在 goroutine 内调用导致竞态
runtime.GOMAXPROCS 和 chunk 大小直接影响吞吐
默认 GOMAXPROCS 是 CPU 核数，但 map 阶段的 goroutine 数不等于核数更优。实际要测：小 chunk（如 100 行/任务）适合 IO 密集型（读文件+解析），大 chunk（如 10k 行）减少调度开销，适合 CPU 密集型（正则匹配+哈希计算）。
- chunk 太小 → goroutine 创建/销毁开销占比上升，
top看到大量runtime.mcall占用 CPU - chunk 太大 → 某个 goroutine 卡住（比如某条脏数据触发 panic）会拖慢全局，且内存峰值高
- 安全做法：先设
numWorkers = runtime.NumCPU()，chunkSize = totalLines / numWorkers，再根据 profile 数据微调
错误处理和中间状态丢失是最大坑点
原生 MapReduce 框架靠 checkpoint 和重试保证 exactly-once，Go 手写版本几乎没这能力。一旦某个 map goroutine panic，整个流程就断，reduce 收不到那部分数据。
- 必须用
recover()包裹每个 map 函数体，记录失败 chunk 的 offset 或 ID，方便后续补跑 - reduce 阶段别直接往全局 map 写，先收集到 slice，再一次性 merge——避免并发写 map panic
- 别在 map 阶段做网络请求或文件写入，这些操作无法原子回滚；真需要，得单独封装成幂等 service
- 调试时加
log.Printf("map done for chunk %d, got %d keys", i, len(res))，比 print 更易定位哪块丢了数据
真正难的不是写完三个函数，而是让失败可追溯、结果可验证、资源不泄漏。生产环境跑之前，至少用 go run -race 过一遍，并模拟一个 goroutine panic 看是否静默丢数据。
