Collections.shuffle() 不生效最常见原因是传入不可变列表，如 Arrays.asList() 返回的列表或某些 ORM 框架返回的只读视图；需用 new ArrayList(originalList) 显式拷贝后再打乱。
为什么直接用 Collections.shuffle() 有时不生效
最常见的情况是：你传给 Collections.shuffle() 的不是可变列表（ArrayList 或 LinkedList），而是 Arrays.asList() 返回的固定大小列表，或者来自 Stream.collect(Collectors.toList()) 但底层被包装成不可修改视图。这类列表调用 shuffle() 不报错，但实际顺序不变。
- 确认列表是否支持
set()操作：执行list.set(0, list.get(0))测试，抛UnsupportedOperationException就说明它只读 - 安全做法是显式创建新
ArrayList：new ArrayList(originalList) - 如果题库数据来自 JSON 或数据库 ORM 映射（如 MyBatis 返回的
List），部分框架默认返回不可修改集合，需主动拷贝
打乱前要不要先深拷贝题目对象
如果你的题目对象（比如 Question 类）含可变字段（如 selectedOption、isAnswered），而试卷生成逻辑会复用原题对象（例如用于后续答题记录），那直接 shuffle 原始列表会导致多个试卷共享同一份题干状态——改一份就全变。
- 仅 shuffle 顺序 → 不需要深拷贝，只要列表本身可变即可
- 要隔离每套试卷的状态 → 必须对每个
Question实例做浅拷贝（new Question(q)）或深拷贝（序列化/反射/克隆） - 简单场景下，用
stream().map(Question::copy).collect(toList())配合自定义copy()方法更可控
Collections.shuffle() 的随机性够不够考试用
它基于 Random（JDK 17+ 默认是 ThreadLocalRandom），满足一般抽题需求，但不适用于密码学强度要求的场景（比如防预测题库排列）。考试系统若需更高随机性或可重现性（如支持“重放同一套卷”），应显式传入带种子的 Random 实例。
- 保证每次生成不同试卷：
Collections.shuffle(list, new Random()) - 固定种子用于调试或存档：
Collections.shuffle(list, new Random(12345L)) - 避免用
Math.random()—— 它和Collections.shuffle()内部机制无关，不能控制其随机源
从题库选题 + 打乱的典型错误链
常见组合操作是「先按难度筛选出 20 道题，再从中随机取 10 道并打乱」，这里容易在 shuffle 前漏掉截断，或 shuffle 后又误用原始索引。
- 错误写法：
list.subList(0, 10).shuffle()→subList()返回的是原列表视图，shuffle()会打乱原列表前 10 项，且无返回值 - 正确链式写法：
new ArrayList(list.stream().filter(...).limit(10).collect(toList()))，再对其 shuffle - 更高效方式（尤其大数据量）：用
Random.nextInt()做蓄水池采样，避免先 collect 再 shuffle 再截断的三重开销
