Go中真正并行的Map函数需用goroutine分片处理、sync.WaitGroup同步、channel收集结果，避免共享内存竞态；Reduce阶段须键导向归并而非顺序拼接，并通过context控制超时与取消。
Go里怎么写一个能真正并行的 Map 函数
Go原生没有 map 或 reduce 标准库函数，所谓“并行”不能靠 for 循环加 go 关键字硬塞——那样容易漏掉同步、竞态、panic传播等问题。
关键点是：必须显式控制 goroutine 数量、用 sync.WaitGroup 等待完成、通过 channel 收集结果（避免共享内存）。
- 别直接对切片索引并发写入，用
make([]T, 0, len(src))预分配再 append 到各自局部切片，最后合并 - 输入数据若含指针或结构体，注意是否可被多个 goroutine 安全读取；修改原始数据需加锁或深拷贝
- 建议封装成泛型函数，约束
func(T) U类型签名，避免类型断言开销 - 错误处理要透出：每个 goroutine 的 panic 必须 recover 并转为 error 发到结果 channel
Reduce 阶段为什么不能简单用 range 遍历中间结果
Map 阶段输出的往往是 []map[K]V 或 [][2]interface{} 这类非统一结构，直接遍历会丢失键的聚合语义——比如单词计数时，“hello” 分散在 3 个 goroutine 的输出里，得按 key 合并值，不是按 slice 下标拼接。
真正的 Reduce 是键导向的归并，不是顺序拼接。
立即学习“go语言免费学习笔记（深入）”；
- 优先用
map[K]V做归并容器，K 必须可比较（不能是 slice、map、func） - 如果 Map 输出是
[][2]interface{}，先做一次类型断言和 key 提取，再累加；否则 runtime panic - 并发 Reduce（如多 goroutine 写同一 map）必须加
sync.RWMutex，但通常不推荐——Map 阶段已分片，Reduce 单 goroutine 处理更安全 - 考虑用
golang.org/x/exp/maps（Go 1.21+）的maps.Clone或maps.Copy辅助合并
如何让 MapReduce 流水线不阻塞、不堆积内存
典型错误是 Map 阶段把全部中间结果塞进一个大 slice，再喂给 Reduce；数据量一大就 OOM。真实场景应流式处理：Map 输出到 channel，Reduce 从 channel 拉取，边收边算。
- Map 阶段用
chan []pair{key, value}输出，每批固定 size（如 1000 条），避免单次发送过大 - Reduce 阶段启动前先 close 接收 channel，防止 goroutine 泄漏；用
for range自动退出 - 若 Reduce 逻辑复杂（如排序、去重），考虑加 buffer channel（
make(chan, N)），N 取 16~64，平衡吞吐与内存 - 务必设置 context 超时或取消，尤其当上游 channel 因错误提前关闭时，Reduce 不应死等
go-zero 的 MapReduce 包不是万能胶
go-zero 提供了 zrpc/internal/mapreduce 和 core/stores/cache/mapreduce.go 等封装，但它默认假设：输入可分片、无状态、Reduce 是纯函数。一旦你的业务有依赖外部 RPC、需要事务回滚、或中间结果带上下文（如 traceID），就得自己接管调度逻辑。
- 它内部用
sync.Pool复用 goroutine，但 pool 对象生命周期不可控，不适合持有长连接或缓存 - 错误处理只返回第一个 panic，其余 goroutine 错误被吞掉——线上排查时容易漏掉根因
- 不支持动态分片策略（如按 key hash 分，而非简单按 index mod N），遇到倾斜数据会拖慢整体
- 若你已经在用
errgroup.Group或pipeline模式，强行套 go-zero 的MapReduce反而增加心智负担
