本文详解 go 语言中多生产者/多消费者并发模型的典型陷阱——全局变量非原子操作引发的数据竞争，演示如何用 `atomic` 替代裸读写，并通过通道协调实现线程安全的序列号分发。
在 Go 并发编程中，「多个 goroutine 同时读写同一变量」是导致不可预测行为的根源之一。你提供的代码看似能稳定输出 1 到 1000 的递增序列，实则掩盖了一个严重问题：seq++（即 seq = seq + 1）不是原子操作，它包含「读取 → 计算 → 写入」三步，在无同步保护下极易发生数据竞争（data race）。
? 为什么没看到重复数字？——表象背后的偶然性
你的程序中：
- requestChan 是无缓冲通道，所有消费者发送请求时会阻塞，直到某个 generateStuff goroutine 从该通道接收；
- generatorChan 同样无缓冲，生产者生成结果后必须等待消费者接收才继续；
- 这种双重通道同步形成了隐式串行化：即使有 20 个生产者，实际任一时刻往往仅有一个 goroutine 在执行 seq++ —— 尤其在 GOMAXPROCS=1（默认单 OS 线程）环境下，调度器倾向于让一个 goroutine 完成整个循环，从而“侥幸”避免了竞态暴露。
但这只是运气好，而非正确。一旦启用多线程（如 GOMAXPROCS=4）、增加负载或稍作扰动（如插入 runtime.Gosched()），竞态便会显现：seq 可能丢失自增、重复赋值，甚至导致程序崩溃。
✅ 正确做法：用原子操作替代共享变量修改
Go 标准库 sync/atomic 提供了对基础类型的安全原子操作。将 seq++ 替换为：
