使用 Collections.shuffle 配合固定种子的 Random 实例可实现完全可复现的洗牌结果，适用于测试、调试等需确定性行为的场景；必须显式传入 new Random(seed) 创建的实例，而非依赖默认内部 Random。
使用 Collections.shuffle 配合固定随机种子，就能让每次洗牌结果完全可复现——这是测试、调试或需要确定性行为时的关键技巧。
指定 Random 实例并传入固定种子
默认的 Collections.shuffle(list) 使用内部创建的 Random 实例，无法控制种子。要实现可控洗牌，必须显式传入一个带种子的 Random 对象：
- 用
new Random(seed)创建确定性随机源，相同种子 → 相同随机数序列 - 调用
Collections.shuffle(list, random)，确保洗牌逻辑依赖该实例 - 种子可以是任意 long 值（如
42L、System.currentTimeMillis()或配置项）
确保列表内容不变的前提下重复验证
只要列表元素和顺序初始一致，且使用相同 seed，多次 shuffle 结果必然相同：
- 避免在 shuffle 前修改列表（如 add/remove），否则基准状态不同，结果自然不同
- 若需多次重置再洗牌，建议每次从原始副本开始（如
new ArrayList(original)） - 注意：对象引用本身不参与随机逻辑，只按索引位置交换；若元素是可变对象，其内部状态不影响 shuffle 过程
结合实际场景的典型用法
常见于单元测试、游戏关卡生成、A/B 实验分组等需要可重现性的场合：
立即学习“Java免费学习笔记（深入）”；
- 测试中：固定 seed + 固定输入列表 → 断言洗牌后顺序符合预期
- 配置化：从配置文件读取 seed，便于环境间结果对齐（如 dev/test/prod 使用不同 seed 但各自稳定）
- 调试时：发现某次 shuffle 结果异常，只需复用当时 seed 即可 100% 复现问题
注意事项与常见误区
看似简单，但几个细节容易导致“以为可控实则不可控”：
- 不要用
new Random(System.nanoTime())—— 每次都不同，失去可控性 - 避免多线程共享同一个 seeded Random 实例做 shuffle（虽线程安全，但并发调用会干扰序列）
- Java 17+ 中
Random默认使用 LXM 算法，但种子行为保持兼容；旧版本（如 Java 8）用 Linear Congruential，同样支持确定性 - 如果用
ThreadLocalRandom.current()，它不接受种子，不能用于可控场景
