正确做法是先构造全集再Fisher-Yates打乱；禁用OrderBy(x=>Guid.NewGuid())，因其排序不稳定、不可复现且有异常风险；多线程需独立Random实例或Random.Shared。
用 Random 生成不重复随机数容易踩哪些坑
直接用 Random 循环调用 Next() 生成“不重复”数字，大概率会重复——因为没做去重逻辑，只是“随机”，不是“随机且不重复”。常见错误是边生成边 Contains 判断，数据量一大就变慢；更隐蔽的坑是多个线程共用同一个 Random 实例，导致种子冲突、序列重复甚至抛 InvalidOperationException。
正确做法是「先构造全集，再打乱」，而不是「边试边筛」。比如要 0–99 中取 10 个不重复整数：
- 别写
while (list.Count （O(n²) 且不可控） - 改用
Enumerable.Range(0, 100).OrderBy(_ => Guid.NewGuid()).Take(10)（简单但有性能代价） - 或更稳的 Fisher-Yates 原地打乱：
int[] arr = Enumerable.Range(0, 100).ToArray(); var rand = new Random(); for (int i = arr.Length - 1; i > 0; i--) { int j = rand.Next(0, i + 1); (arr[i], arr[j]) = (arr[j], arr[i]); } var result = arr.Take(10).ToArray();
Guid.NewGuid() 打乱真的随机吗？为什么有人反对
Guid.NewGuid() 生成的是全局唯一标识符，不是为随机排序设计的。它底层依赖系统时间、MAC 地址、CPU 计数器等，虽然“看起来”分散，但 OrderBy(x => Guid.NewGuid()) 每次比较都新建一个 Guid，导致排序过程不稳定——.NET 的 OrderBy 不保证稳定排序，而 Guid 之间无自然序关系，可能触发内部异常或返回非预期顺序（尤其在 .NET 6+ 的优化排序实现中）。
这不是理论风险：实际运行中可能出现 ArgumentException: At least one object must implement IComparable（虽少见），更多是逻辑难验证、结果不可复现、单元测试失败。
- 别用
OrderBy(x => Guid.NewGuid())做核心业务的打乱逻辑 - 测试环境里它可能“凑合能用”，但上线后并发一高，
Guid创建频率激增，还可能拖慢 GC - 真正需要可重现的打乱？传入固定种子的
Random实例，比如new Random(42)
打乱 List 的三种写法性能和线程安全对比
对一个 List<int></int> 打乱，选哪种取决于你是否关心性能、是否多线程、是否需复现。
-
list.OrderBy(x => rand.Next()).ToList()：每次比较都调Next()，比较次数 ≈ O(n log n)，且分配大量临时对象，内存压力大 -
list.Shuffle(new Random())（扩展方法，Fisher-Yates）：O(n)，原地交换，零额外分配，推荐用于大多数场景 -
list.AsParallel().OrderBy(x => Guid.NewGuid()).ToList()：看似快，实则错——并行 + 非确定性键 = 结果不可靠，还可能死锁或抛AggregateException
线程安全方面：Random 实例不是线程安全的，多线程打乱必须每个线程用独立实例，或改用 Random.Shared（.NET 6+）。
用 System.Security.Cryptography.RandomNumberGenerator 替代 Random 的必要场景
普通业务打乱不需要加密级随机数，但如果你在做抽奖、密钥派生、Token 生成、或者合规要求（如金融/游戏防作弊），那 Random 的可预测性就是硬伤——它基于种子，只要知道种子和调用次数，就能还原全部序列。
-
RandomNumberGenerator是真随机（基于 OS 底层熵源），但开销大，别用来打乱 1000 个元素的列表 - 折中方案：用它生成一个高质量种子，喂给
Random，比如var seed = BitConverter.ToInt32(RandomNumberGenerator.GetBytes(4)); var rand = new Random(seed); - 注意：
RandomNumberGenerator是IDisposable，记得用using或确保释放
真正复杂的地方不在“怎么写”，而在“为什么不能只图省事用 Guid.NewGuid()”——它掩盖了随机性来源、可预测性、可测试性这三层问题，而这些在灰度发布或审计时才突然冒出来。
