高并发下rand.Intn()因全局锁导致QPS骤降，正确做法是每个goroutine持独立*rand.Rand实例或用sync.Pool复用；其性能瓶颈源于单实例串行争锁，即使读操作也需更新原子计数器，争用不可避免。
高并发下直接用 rand.Intn() 会锁全局源，QPS 上不去；正确做法是每个 goroutine 持独立 *rand.Rand 实例，或用 sync.Pool 复用——不是“要不要换”，而是“不换就卡住”。
为什么 rand.Intn() 在压测时突然变慢？
它背后是单个带互斥锁的全局 *rand.Rand 实例。所有 goroutine 都串行抢同一把锁，pprof 里一眼看到 runtime.futex 占比飙升。哪怕只是读操作（如 Intn()），内部也要更新原子计数器，争用不可避免。
- Go 1.20+ 虽默认初始化了全局源，但没解决并发瓶颈
- 同一秒内多个 goroutine 调
time.Now().UnixNano()可能拿到相同种子 → 随机序列雷同 - 别在循环里反复
rand.New(rand.NewSource(time.Now().UnixNano()))—— 种子过期快，且分配开销白费
每个 goroutine 自建 *rand.Rand 实例怎么写？
结构体仅约 40 字节，分配成本极低，且彻底消除锁竞争。关键是种子必须差异化：
- 简单场景：用
time.Now().UnixNano() ^ int64(goroutineID)，其中goroutineID可粗略用uintptr(unsafe.Pointer(&i))（注意：非标准，仅作区分） - 生产推荐：启动时用
crypto/rand.Read()生成一次 8 字节种子，缓存复用 —— 不进热路径，又避免时间精度陷阱 - 示例：
r := rand.New(rand.NewSource(time.Now().UnixNano() ^ int64(id)))
用 sync.Pool 复用 *rand.Rand 的坑在哪？
Pool 能减分配压力，但对象可能被 GC 回收，每次 Get() 后状态不可信。不能依赖它“自动重置”：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 错：在
Pool.New里写rand.New(rand.NewSource(time.Now().UnixNano()))—— 种子老化，复用越久越假 - 对：New 函数用预生成的加密种子构造实例；或
Get()后立刻调r.Seed(time.Now().UnixNano())（Go - 更稳：Pool 存的是已设好种子的干净实例，New 时只做一次
crypto/rand.Read()，不碰时间
什么时候必须切到 crypto/rand？
不是因为“更随机”，而是因为“不能被预测”——只要涉及 token、session ID、salt、UUID v4，math/rand 再快也不能用。
-
crypto/rand.Read()在 Linux 上批读/dev/urandom，10K goroutine 并发下实测比加锁的math/rand还快 - 别自己拼
rand.Int63() + fmt.Sprintf造 token —— 分布不均、长度不定、不安全 - 生成 16 字节 token：
b := make([]byte, 16)<br>_, err := rand.Read(b)
记得检查err
真正容易被忽略的，是“全局函数只适合单 goroutine 临时用”这个边界——一旦逻辑从 CLI 工具挪到 HTTP handler，或从单测跑进压测环境，不隔离实例，性能断崖就来了。
