Collections.shuffle()实现抽奖系统核心是“打乱再取头”，基于Fisher-Yates算法确保每人中奖概率相等、所有排列等可能；支持分层取号、多轮独立洗牌、SecureRandom高安全注入及题库/菜单等顺序置换场景。
用 Collections.shuffle() 实现抽奖系统，核心就一句话：打乱再取头。它不靠猜、不靠重试、不靠去重，靠的是 Fisher-Yates 算法保证的数学公平性——每人中奖概率完全相等，且所有排列出现机会均等。
年会抽奖：一次洗牌，分层取号
公司有 87 名员工，要抽 1 名特等奖、3 名一等奖、5 名二等奖。不用循环随机选、也不用反复剔除已中奖者：
- 把全部员工姓名放进
ArrayList<String>（不能用Arrays.asList()直接返回的只读列表） - 调用
Collections.shuffle(employees)—— 一行完成全局随机化 - 按顺序截取：
winners.subList(0, 1)是特等奖，subList(1, 4)是一等奖，subList(4, 9)是二等奖
这种方式天然避免重复，逻辑清晰可审计，结果也容易复现（若传入固定 Random(123L)）。
多轮抽奖：动态过滤 + 每轮独立洗牌
某线上活动持续 7 天，每天抽 10 人，且同一用户不可重复中奖。关键不是“全局洗一次”，而是每轮前做减法：
- 维护一个原始全量用户列表
allUsers - 每轮开始时，用
new ArrayList<>(allUsers)创建副本 - 从副本中移除历史中奖者（
removeAll(winnerHistory)） - 对剩余列表调用
Collections.shuffle()，再取前 10 个
既保证单轮公平，又守住“不重复”业务规则，比每次从全量池里抽+校验+重试更稳定、更高效。
高安全抽奖：用 SecureRandom 替代默认 Random
当抽奖关联真实奖金、NFT 或链上权益时，普通 Random 的时间种子可能被预测。此时应显式注入加密级随机源：
- 改用
Collections.shuffle(participants, new SecureRandom()) -
SecureRandom基于操作系统熵池，抗预测性强，适合金融级场景 - 注意它线程安全，无需额外同步；性能损耗在百人级抽奖中几乎不可感知
顺便提醒：不要对同一列表并发调用 shuffle，若多线程共用，需加锁或使用线程局部副本。
题库/菜单/商品卡片的顺序置换
这不是传统抽奖，但逻辑同源——需要每次展示不同顺序，又不想耦合随机逻辑：
- 比如考试系统从 50 道题中随机出 10 道，且题干顺序也要打乱
- 先
shuffle(questionList)，再subList(0, 10)取题，再对这 10 道题shuffle()一次调整顺序 - UI 轮播位、推荐商品流、甚至后台任务调度队列，都可用同样模式轻量实现“伪随机轮换”
只要数据封装在可变 List 中，shuffle 就是最直接、最可靠、最不易出错的顺序控制方式。
