直接用Collections.shuffle()有时没效果，根本原因是传入了不可变List（如UnmodifiableList）或未注意泛型擦除；该方法要求List支持set()操作，否则静默失败或抛UnsupportedOperationException。
为什么直接用 Collections.shuffle() 有时没效果？
常见现象是调用后 List 看起来没变，或者在多线程环境下结果不可预测。根本原因通常是传入了不可变 List（比如 Arrays.asList() 返回的）或未注意泛型擦除导致的类型不匹配。该方法会原地修改传入的 List，但要求 List 实现了 set(int, E) 方法——而 Arrays.asList() 返回的 List 虽可读写，但底层数组固定长度，add()/remove() 会抛异常，shuffle() 却能工作；不过若 List 被包装成 UnmodifiableList，就会静默失败或抛 UnsupportedOperationException。
实操建议：
- 确认 List 是可修改的：优先用
new ArrayList(originalList)包一层再 shuffle - 避免对
Arrays.asList(...)结果直接 shuffle 后又试图 add/remove - 若 List 来自 Stream.collect(Collectors.toList()) 或其他不可变构造，请先复制
Collections.shuffle() 的随机源怎么控制？
默认使用系统当前时间纳秒 + 纳米级计时器生成种子，适合一般场景；但测试时需要可重现结果，就得手动传入 Random 实例。
实操建议：
- 测试中固定种子：用
Collections.shuffle(list, new Random(42L)) - 高安全性场景（如抽奖、密码学相关）不要依赖默认 Random，改用
SecureRandom：Collections.shuffle(list, new SecureRandom()) - 注意
SecureRandom初始化可能阻塞（尤其在熵不足的容器环境），生产中需预热或复用实例
打乱子列表（subList）要注意什么？
对 list.subList(fromIndex, toIndex) 的返回值直接 shuffle 是合法的，但必须清楚：它操作的是原 List 的视图，不是副本。任何 shuffle 操作都会真实改变原 List 对应区间的元素位置。
实操建议：
- 若只想打乱局部区间，且不影响其余部分，直接 shuffle subList 即可，无需复制
- 但 subList 不支持
add()/remove()，所以 shuffle 安全；不过若原 List 同时被其他线程修改，subList 可能抛ConcurrentModificationException - 别对 subList 结果再次调用
subList()后 shuffle——嵌套视图容易引发 IndexOutOfBoundsException
替代方案：不用 Collections.shuffle 怎么安全打乱？
当 List 是只读接口（如 Collection）、或你无法确保其实现类支持 set()（比如某些自定义不可变集合），就不能直接调用 Collections.shuffle()。此时需手动实现 Fisher-Yates 洗牌算法并返回新 List。
实操建议：
- 简单复制+洗牌：
List<t> shuffled = new ArrayList(original); Collections.shuffle(shuffled);</t> - 函数式风格（Java 16+）：用
Stream.iterate+Random::nextInt实现，但性能差、不易调试，不推荐 - 真正不可变场景下，老老实实用 for 循环 +
Random.nextInt(i + 1)手写 Fisher-Yates，并收集到新 ArrayList 中
Fisher-Yates 算法本身很简单，但边界条件（比如从 size - 1 开始倒序、随机索引上限为 i 而非 i + 1）一旦写错，就会引入偏差——这点很容易被忽略，也很难通过肉眼测试发现。
