因为 rand.Intn 使用全局 rand.Rand 实例且内部加 sync.Mutex 全局锁，200 个 goroutine 高频调用时在锁上激烈竞争，导致 CPU 利用率卡在 50%~75%；正确解法是为每个 goroutine 分配独立的 rand.Rand 实例，并用唯一种子（如 time.Now().UnixNano() ^ int64(id)）避免序列重复。
为什么 rand.Intn 一并发就卡住
因为 rand.intn 调用的是全局 *rand.rand 实例，其内部方法被 sync.mutex 完全保护。200 个 goroutine 同时调用时，并非并行计算，而是在同一把锁上排队等待——cpu 大量空转，实测利用率常卡在 50%~75%，哪怕机器有 16 核也跑不满。
每个 goroutine 必须配独立的 *rand.Rand 实例
这是最直接、零依赖、效果立竿见影的解法。关键不是“新建”，而是“隔离”：
- 不要复用同一个
*rand.Rand实例传给多个 goroutine - 种子必须唯一：仅用
time.Now().UnixNano()在高并发下极易重复（纳秒级时间戳相同），导致多个 goroutine 生成完全一致的随机序列 - 推荐组合种子：
time.Now().UnixNano() ^ int64(runtime.GoID())（Go 1.21+）；若用旧版本，可用atomic.AddInt64(&seedCounter, 1)替代 goroutine ID - 实例创建开销极小，无需缓存到
sync.Pool——除非你每秒新建数万 goroutine
示例：
func worker(id int) {
seed := time.Now().UnixNano() ^ int64(id) // 简单可靠，id 可来自参数或 atomic 计数
r := rand.New(rand.NewSource(seed))
for i := 0; i < 1e6; i++ {
_ = r.Intn(100)
}
}
别碰 rand.Seed，也别在循环里重播种
rand.Seed 在 Go 1.20+ 已弃用，且它只影响全局实例——这正是你要避开的瓶颈源。更危险的是，在热循环里反复调用它：
- 每次调用都重置全局生成器状态，导致后续
rand.Intn返回值高度可预测甚至重复 -
time.Now().UnixNano()在纳秒级密集调用中返回相同值，播种后立刻得到相同序列 - 性能雪上加霜：播种本身含内存写和算法初始化，比单纯生成一个整数还重
正确做法：全局实例彻底不用；独立实例只在初始化时播一次种，之后全程无锁调用。
math/rand/v2 还没发布，别等它救急
Go 1.22 将带 math/rand/v2，它默认移除全局状态、改用 PCG-DXSM 生成器、引入 Lemire 算法加速 Intn——但当前（2026年5月）尚未正式 GA。生产环境不能押注 v2，现在就得用已验证的方案落地。
真正卡住的从来不是算法，是你让 200 个 goroutine 轮流抢同一把锁。只要每个 goroutine 拿到自己的 *rand.Rand，锁就消失了，多核利用率立刻拉满——这个动作本身没有隐藏条件，但种子唯一性极易被忽略。
