Random.nextInt() 不能直接生成[a,b]区间，因其nextInt(bound)仅支持[0,bound)且bound>0；正确做法是rand.nextInt(b-a+1)+a。
Random.nextInt() 为什么不能直接生成 [a, b] 区间？
因为 Random.nextInt(int bound) 只能生成 [0, bound) 的整数，左闭右开，且不支持负下界。想得到 [a, b]（含 a 和 b），得手动平移和扩容——不是调用一次就能搞定的事。
- 常见错误：写成
rand.nextInt(b - a)，结果范围是 [0, b-a)，漏掉 a，也达不到 b - 正确做法是：先算长度
b - a + 1，再偏移a，即rand.nextInt(b - a + 1) + a - 注意：a 和 b 必须满足
a ，否则 <code>b - a + 1≤ 0，会抛IllegalArgumentException - 如果 a、b 是负数（比如 [-5, 5]），公式依然成立，但别手抖写成
nextInt(-5 + 5 + 1)——负号容易看漏
用 ThreadLocalRandom 替代 Random 更安全吗？
在多线程环境下，是的。普通 Random 实例共享内部状态，高并发时可能因 CAS 重试导致性能下降；ThreadLocalRandom 每个线程一份实例，无竞争。
- 适用场景：Web 后端、批量任务、并行流中生成随机数
- 不能用
new ThreadLocalRandom()—— 它是抽象类，必须用静态方法ThreadLocalRandom.current() - 它的
nextInt(a, b)是**直接支持闭开区间 [a, b)** 的！比 Random 少一步换算：ThreadLocalRandom.current().nextInt(1, 7)就是模拟骰子（1~6） - 但注意：它没有
nextInt(a, b)的闭闭重载，[a, b] 还得自己加 1：nextInt(a, b + 1)
生成 double 随机数时，nextDouble() 的范围陷阱
Random.nextDouble() 固定返回 [0.0, 1.0)，不是 [0.0, 1.0]，永远取不到 1.0。这个边界行为会影响某些需要“全覆盖”的场景，比如按概率分桶。
- 想得到 [a, b) 的 double：用
rand.nextDouble() * (b - a) + a - 想严格包含 b（即 [a, b]），不能简单加一个极小值（如
+ Double.MIN_VALUE），浮点精度会导致不可控；更稳妥的是用整数缩放再转回 double，例如生成 6 位小数精度的 [a, b]：(rand.nextInt((int)((b - a) * 1e6 + 1)) / 1e6) + a - 如果用
ThreadLocalRandom.current().nextDouble(a, b)，它也是 [a, b)，和 nextDouble() 一致，不是闭区间
SecureRandom 什么时候该上？
当随机数用于密码学用途（如生成 token、盐值、密钥）时，必须用 SecureRandom，它基于操作系统熵源，不可预测；普通 Random 或 ThreadLocalRandom 是伪随机，种子可被推测。
立即学习“Java免费学习笔记（深入）”；
- 性能代价明显：初始化慢，生成速度比 Random 低 1~2 个数量级
- 别为了“更安全”滥用它——ID 生成、抽样、游戏逻辑等非安全场景，用
ThreadLocalRandom足够 - 构造时别用
new SecureRandom(byte[])手动设种子，除非你真懂熵池和重放风险；默认构造器最稳妥 - 它没有
nextInt(a, b)便捷方法，仍需手动换算，且nextLong()等方法不支持范围参数
边界计算和类型选择是最容易出错的地方：一个加减号写反，或把闭开区间记混，就可能让随机数永远卡在某个边缘值上。实际写的时候，建议把范围表达式单独提成常量或私有方法，别堆在业务逻辑里反复手算。
