Random.nextInt(int bound) 的 bound 是不包含的上限，生成 [0, bound) 范围整数；需通过 nextInt(max - min + 1) + min 实现 [min, max] 闭区间随机数。
Random.nextInt(int bound) 的 bound 是「不包含」的上限
Java 中 Random.nextInt(int bound) 生成的是 [0, bound) 范围内的整数，即从 0 开始、到 bound - 1 结束。抽奖号码如果要求是 1～100，直接传 nextInt(100) 会得到 0～99，漏掉 100、多出 0——这和业务需求完全对不上。
正确做法是：把目标范围「右移一位」再调用。比如要 1～100（含），就写 nextInt(100) + 1；要 5～20（含），就写 nextInt(20 - 5 + 1) + 5。
- 通用公式：
random.nextInt(max - min + 1) + min -
min和max都是闭区间端点，必须满足min ，且max - min + 1不能溢出 int - 如果
min == 0，可简化为nextInt(max + 1)，但建议统一用通用公式，避免混淆
用 SecureRandom 替代 Random 应对抽奖安全要求
普通 Random 是线性同余算法，可被预测，一旦种子被知晓，后续所有“随机”号码都能复现——这对抽奖活动是严重风险。生产环境尤其是带奖品的活动，必须用 SecureRandom。
SecureRandom 基于操作系统熵源（如 /dev/urandom），不可预测，但性能略低，不过抽奖这种低频操作完全无感。
- 初始化方式：
new SecureRandom()即可，无需手动设置 seed - 用法和
Random一致：secureRandom.nextInt(100) + 1 - 避免重复创建实例：把它声明为
static final成员变量，复用同一个实例
避免重复中奖号码：用 Set 去重比循环重试更可控
抽奖常需生成 n 个互不相同的幸运号码。有人习惯“while 循环 + if 判重”，但当范围接近抽取数量时（比如从 100 个号里抽 95 个），碰撞概率飙升，可能卡住或耗时不可控。
更稳的方式是先构建候选池，再打乱后取前 n 个：
List<integer> candidates = IntStream.rangeClosed(1, 100).boxed().collect(Collectors.toList()); Collections.shuffle(candidates, new SecureRandom()); // 用 SecureRandom 打乱 List<integer> winners = candidates.subList(0, 10); // 抽 10 个</integer></integer>
- 适合总数可控（比如 ≤ 10⁵）的场景；若范围极大（如 1～10⁹），再改用 reservoir sampling 等流式算法
-
Collections.shuffle()内部用 Fisher–Yates，时间复杂度 O(n)，比反复碰撞靠谱得多 - 务必传入
SecureRandom实例，否则默认用Random，安全性归零
注意 nextInt() 在多线程下的线程安全问题
Random 实例本身不是线程安全的：多个线程并发调用它的 nextInt()，可能破坏内部状态，导致返回值异常（比如固定返回 0，或抛 ArrayIndexOutOfBoundsException）。而 SecureRandom 的大多数实现是线程安全的，但文档未强制保证。
- 最稳妥方案：每个线程用独立实例，或用
ThreadLocal封装 - 或者直接用
ThreadLocalRandom.current().nextInt(100) + 1—— 它专为多线程设计，性能更好，且自动绑定当前线程 - 不要在静态工具类里暴露一个共享的
Random实例供全局调用
实际抽奖逻辑里，边界计算、随机源选择、去重策略、线程模型这四点只要错一个，轻则号码发重、漏号，重则被人逆向预测中奖结果。尤其别图省事用 Math.random() 或裸 Random，那不是抽奖，是公开摇号。
