根本原因是未正确同步goroutine生命周期及并发写map，应使用channel+WaitGroup协调、避免共享map、合理设计channel类型与缓冲区，并采用worker pool而非每任务一goroutine。
goroutine + channel 实现 MapReduce 时，为什么结果总是漏掉或重复？
根本原因在于没有正确同步 goroutine 的生命周期，main 函数提前退出，或多个 goroutine 并发写同一个 map 而没加锁。Go 的 map 非并发安全，直接在多个 goroutine 里 m[key] = val 会触发 fatal error: concurrent map writes。
- 用
sync.Map替代原生map，或更推荐：每个 goroutine 输出到独立 channel，由单个 collector goroutine 统一收集、合并 - 必须用
sync.WaitGroup等待所有 map goroutine 完成，再关闭 map 结果 channel；reduce goroutine 需用for range读取直到 channel 关闭 - 别在 goroutine 里直接往全局 slice 追加 ——
append可能导致底层数组扩容，引发数据竞争
如何设计 channel 类型和缓冲区大小才不卡死？
channel 类型决定数据流结构，缓冲区大小影响吞吐与内存占用。太小容易阻塞 map 阶段，太大可能吃光内存；类型不匹配（比如把 struct{Key string; Count int} 发到 chan string）会编译失败。
- map 阶段输出 channel 建议用结构体指针或自定义类型，例如
chan *KeyValue，避免值拷贝开销 - 缓冲区大小建议设为 map goroutine 数量 × 预估每 goroutine 输出项数（如 100），即
make(chan *KeyValue, numWorkers*100) - reduce 阶段输入 channel 必须和 map 输出类型一致；若需分组，先用
map[string][]*KeyValue在 collector 中聚合，再发给 reduce goroutine
实际跑起来很慢，是 goroutine 开太多还是 channel 用错了？
性能瓶颈常不在 goroutine 数量本身，而在 channel 通信模式和数据粒度。每处理一个字符串就发一次 chan，比批量发送慢一个数量级；同时启动 1000 个 goroutine 处理小任务，调度开销反而压倒计算收益。
- map 阶段按 chunk 分配任务，比如把切片按
len(data)/numWorkers切分，每个 goroutine 处理一块，最后统一发结果 - 避免「一个 item → 一个 goroutine」的写法，改用 worker pool 模式：固定几个 goroutine 从任务 channel 拿任务执行
- 如果 reduce 是纯 CPU 计算（如求和、拼接），别用 channel 传中间结果，改用
sync.WaitGroup+ 共享变量（加锁）或sync/atomic更快
错误信息 all goroutines are asleep - deadlock! 怎么快速定位？
这是最典型的 channel 死锁，说明至少有一个 goroutine 在等 channel 收发，但没人去收/发。常见于：忘记关闭 channel、range 读取未关闭的 channel、goroutine 启动后没发数据就退出。
立即学习“go语言免费学习笔记（深入）”；
- 检查所有
for range ch循环，确认对应 channel 一定被某个 goroutineclose(ch)—— 且只 close 一次 - 用
select加default避免无限等待，尤其调试时：select { case v := - 运行时加
-race参数编译：go run -race main.go，能捕获多数 channel 使用误用和竞态
真正难调的是那种「逻辑上该关但没关」的情况——比如某个 map goroutine 因 panic 提前退出，没走到 close 语句。所以 collector 侧最好带超时或计数校验，别盲目等。
