本文详解 go 多生产者/多消费者场景中常见的数据竞争问题，揭示全局变量非原子操作的风险，并通过 `atomic` 包和通道协作实现线程安全的序列生成，附可运行示例与调试建议。
在 Go 的并发模型中，多生产者-多消费者（MPMC） 是一个经典但极易踩坑的模式。你提供的代码看似能稳定输出 1–1000 的递增序列，实则掩盖了一个严重问题：对全局变量 seq 的非同步读写——这构成了典型的数据竞争（data race）。
? 为什么“看起来正常”？—— 并发的假象
你的代码中，20 个 generateStuff goroutine 共享并修改 seq：
seq = seq + 1 // ❌ 非原子操作：读取 → 计算 → 写入，三步间可被抢占
理论上，若两个 goroutine 同时执行该行，可能都读到 seq=5，各自加 1 后都写回 6，导致丢失一次递增。但实际运行中未观察到重复或跳变，原因在于：
- GOMAXPROCS=1（默认）：单 OS 线程调度下，goroutine 协作式让出（如 channel 阻塞），降低了并发抢占概率；
- requestChan 和 generatorChan 均为无缓冲通道：天然形成同步点，使 goroutine 串行化地“排队”访问 seq，偶然掩盖了竞态；
- 竞争窗口极小：在单核上，两次读-改-写操作重叠概率低，但不等于不存在——这是非确定性 bug，而非正确逻辑。
⚠️ 关键认知：“没出错” ≠ “安全”。数据竞争是未定义行为（UB），可能导致静默错误、崩溃、结果错乱，且在高负载、多核或不同 Go 版本下极易复现。
✅ 正确解法：用原子操作替代共享变量
修复核心在于消除对 seq 的竞态访问。推荐使用 sync/atomic 包的原子增操作：
import "sync/atomic" // 替换 seq = seq + 1 为： s := atomic.AddUint64(&seq, 1) // ✅ 原子读-增-写，返回新值
atomic.AddUint64 保证整个操作不可分割，无论多少 goroutine 并发调用，seq 的最终值必为准确递增（1000 次调用 → seq==1000），且每个返回值唯一。
