go 的 math/rand 生成伪随机数，不设种子时默认用固定种子 1，故 rand.intn(100) 总返回 83；需用 rand.new(rand.newsource(time.now().unixnano())) 初始化，闭区间 [min,max] 应写为 min + r.intn(max-min+1)，float64() 返回 [0.0,1.0)。
Go 的 math/rand 生成的不是真随机数，而是伪随机数；不设种子或用错方式，程序每次运行都会输出完全相同的序列——这不是 bug，是设计使然。
为什么 rand.Intn(100) 总是返回 83？
因为没初始化种子，math/rand 默认使用固定种子 1，所有函数（如 Intn、Float64）都基于这个确定性源。你看到的“随机”，其实是可完全复现的数学序列。
- 旧写法（Go rand.Seed(time.Now().UnixNano())，但该函数已在 1.20+ 被弃用
- 新写法（推荐，全版本通用）：创建独立实例
r := rand.New(rand.NewSource(time.Now().UnixNano())) - 测试/压测需要可复现？把
time.Now().UnixNano()换成固定值，比如rand.NewSource(42)
如何生成 [1, 6] 的骰子点数？
Intn(n) 返回的是 [0, n)（左闭右开），所以不能直接写 r.Intn(6) 就当 1~6 —— 它实际给的是 0~5。
- 闭区间
[min, max]正确写法：min + r.Intn(max-min+1) - 骰子（1~6）→
1 + r.Intn(6) - 日期范围（比如 2020~2025 年）→
2020 + r.Intn(6) - 别用
r.Intn(6) + 1这种“看起来对”的写法代替公式，它只是上式的特例，换范围容易出错
Float64() 为什么永远不等于 1.0？
r.Float64() 返回的是 [0.0, 1.0) —— 包含 0.0，但严格小于 1.0。这是 IEEE 754 浮点表示和算法实现决定的，不是精度误差。
立即学习“go语言免费学习笔记（深入）”；
- 要映射到
[a, b)：用a + r.Float64()*(b-a) - 要包含
b（即[a, b]）？理论上需加 epsilon，但绝大多数场景不需要；若真强求，应改用big.Float或自定义分布 - 生成布尔值更推荐
r.Intn(2) == 0，比r.Float64() 更直观、无浮点陷阱
并发调用 rand 会卡死或变慢吗？
同一个 *rand.Rand 实例是并发安全的（内部有 mutex），但高并发下锁争用会导致性能下降；而全局函数（如 rand.Intn）也共享同一把锁，问题更隐蔽。
- Web 服务中每个 handler 都用
rand.Intn？建议提前声明一个包级变量：var globalRand = rand.New(rand.NewSource(time.Now().UnixNano())) - 极致性能要求（如每秒百万次随机）？考虑为 goroutine 分配独立
*rand.Rand，或用sync.Pool复用 - 绝对别在循环里反复调用
rand.New(rand.NewSource(...))—— 创建 seed 源有开销，且纳秒时间可能重复（尤其在短时密集调用中）
最常被忽略的点：不是“怎么生成”，而是“谁在生成”。用错实例（比如误用全局函数又忘了 init）、在热路径反复新建 Rand、或在测试中混用时间种子和固定种子——这些才是线上随机逻辑失灵的真正原因。
