Go的map不能直接并发读写，因其原生非线程安全，运行时会panic；应使用sync.Map（仅限读多写少）或map+sync.RWMutex，并注意channel关闭与goroutine生命周期管理。
为什么 Go 的 map 不能直接并发读写
因为 Go 运行时对 map 的并发读写做了 panic 保护——只要一个 goroutine 写、另一个同时读，就会触发 fatal error: concurrent map read and map write。这不是 bug，是设计使然：原生 map 非线程安全，且加锁成本高、易误用。
常见错误现象：
• 启动多个 goroutine 往同一个 map 里塞结果
• 在 range 遍历 map 的同时，另一个 goroutine 调用 delete 或赋值
• 用 sync.Map 却当成普通 map 直接取值（m[key] 会报错）
- 真正需要并发读写的场景（如 reduce 阶段聚合中间结果），优先用
sync.Map，但只用它提供的方法：Load、Store、Range - 如果 key 类型固定、数量可控，更推荐用
map+sync.RWMutex：读多写少时性能更好，且语义清晰 -
sync.Map不支持len()，遍历时必须用Range回调，不能直接转切片
如何用 goroutine 模拟 MapReduce 的分片与合并
MapReduce 的核心不是“分布式”，而是“分而治之 + 归并”。Go 里不需要框架，靠 channel 和 goroutine 就能干净实现。
使用场景：
• 处理一批日志文件，统计每个 IP 出现次数
• 批量解析 JSON 数据，提取字段后按类型归类汇总
立即学习“go语言免费学习笔记（深入）”；
- Map 阶段：把输入切片（如
[]string）按 chunk 分发给多个 goroutine，每个返回map[K]V或[]pair；别用共享map收集，用 channel 发回结果 - Reduce 阶段：启动一个 goroutine 从 channel 接收所有
map结果，用本地普通map合并（此时无并发） - 注意 channel 容量：如果 map 数量大、单个结果大，用带缓冲 channel（如
make(chan map[string]int, 10)），避免 sender 阻塞
sync.Map 在 Reduce 阶段的典型误用
有人想省事，在 reduce goroutine 里直接往 sync.Map 里 Store，以为能避免锁；结果发现性能比串行还差，甚至数据丢失。
原因：
• sync.Map 适合「读远多于写」且 key 集合变化不大的场景（比如配置缓存）
• Reduce 是密集写入（成千上万个 key 逐个 Store），内部哈希重散列开销大
• 它的 Range 是快照语义，中途写入不保证被遍历到
- Reduce 必须用普通
map+ 最终一次性合并：每个 goroutine 输出自己的map[string]int，主 goroutine 用循环for k, v := range subMap { result[k] += v } - 如果 reduce 后还要高频读，再把最终结果塞进
sync.Map供后续查询 - 永远不要在
Range回调里调用Store或Delete—— 行为未定义
channel 关闭与 range 的边界问题
模拟 MapReduce 时，常因 channel 关闭时机不对，导致部分结果丢失或 goroutine 永久阻塞。
典型错误：
• 在所有 map goroutine 启动后立刻 close(ch)，但有些还没发完结果
• 用 for range ch 接收，却没等所有 goroutine 结束就退出
- 正确做法：用
sync.WaitGroup计数 map goroutine，仅在Wait()返回后关闭 channel - reduce 端用
for range ch安全，它会在 channel 关闭且缓冲清空后自动退出 - 如果中间要加超时或取消，改用
select+context.WithTimeout，别依赖 channel 关闭来中断
最易被忽略的一点：goroutine 泄漏比数据错更难排查。每次起 goroutine，都要明确它的生命周期由谁控制、何时退出、channel 是否一定被关。MapReduce 模拟本身很简单，卡住的地方永远在并发控制的毛细血管里。
