给你一组数组，比如题库里的几十道题、一份待抽奖的用户 ID、一叠歌曲，你需要把它们打乱。第一反应写出来的代码是什么？我见过太多人直接arr.sort(() => Math.random() - 0.5)，看起来只有一行，跑起来也确实变成乱序了，可一旦拿去做线上活动，某些顺序出现的频率会高得不正常。数组乱序这件事，难点从来不是“能不能变乱”，而是“乱得是否均匀、能不能在可控的复杂度下完成”。这篇文章我会把三种常见实现摆到台面上对比：排序随机法、逐个抽取法、原地交换洗牌法，说清楚各自原理、坑在哪里、项目里到底该选哪种。适合刚入门的前端开发者，也适合准备算法面试的人，哪怕你已经写了两年业务代码，看完都值得回去检查一下自己项目里的 shuffle 到底是怎么写的。
1. 乱序到底在乱什么：先回答三个关键问题
1.1 乱序的业务场景其实比你想的多
乱序不是算法题专属。随便列几个真实场景：考试系统的试题顺序要打散，避免相邻考生互相参考；音乐软件播放列表要随机；推荐流需要把候选内容随机排序；做机器学习本地训练时，数据要先 shuffle 再分 batch；就连活动里的抽奖转盘，也经常把一批用户 ID 打乱后按顺序取。这些场景里，数组是同一个数组，乱序的目标却分两种：一种只要求“看起来别太整齐”，另一种则要求“每个元素出现在任意位置的概率必须接近相等”。
区分这两种目标非常重要。很多实现看起来都能跑，但目标不同，能接受的实现就完全不同。比如展示用的推荐列表，稍微不均匀用户根本感知不到；但如果是抽奖逻辑，直接决定“谁先谁后”或者“是否会偏向某个分组”，就必须要数学上站得住脚的均匀分布。我后面会提到的最短写法，恰恰是在“较真”的时候最容易出问题的那一个。
1.2 判断一个乱序实现好不好的三把尺子
做乱序，第一步是定义什么叫“好”。我通常会看两个硬指标，再加一条附加标准。
第一是均匀性。对 n 个元素的数组，理论上每一种排列出现的概率都应该是 1/n!。实际操作中很难验证全部排列，因为 n 一上来就是几千几万，排列数量爆炸式增长，所以通常退一步，统计“某个元素出现在某个位置 j 的概率”是否接近 1/n。如果每个元素在每个位置上的频次都差不多，就认为这个乱序是基本均匀的。
第二是时间复杂度。数组规模小的时候无所谓，但数据量到几万甚至几十万时，一个 O(n²) 的实现会让你在浏览器里明显看到卡顿。能不能原地操作、要不要额外数组，也是考察点。
第三是副作用：是否保留原数组。有些场景要求不修改入参，有些则允许原地打乱。实现方式必须和函数签名匹配。函数返回新数组和直接改原数组，在工程上是两套不同的约定，混用很容易出 bug。
很多人还会纠结随机源用Math.random()够不够。这里先给个结论：对于前端展示、抽奖、洗牌这类场景，Math.random()的伪随机特性在统计上足够用。真正的随机性缺陷往往不在随机源，而在算法本身。只有安全级别很高的场景（比如对抗性抽奖）才需要换随机源，这点我放到最后展开。
1.3 三种实现的定位一目了然
下文要展开的三种方式，可以看作一条从“最快写出来”到“写对写好”的演进路径。先用一张表建立整体印象：
| 实现 | 核心思路 | 时间复杂度 | 均匀性 | 主要问题 |
|---|---|---|---|---|
| 排序随机法 | 让排序比较器随机返回正负 | O(n log n) | 较差 | 比较器不稳定，排列概率明显不均 |
| 逐个抽取法 | 每次随机抽一个元素放入新数组 | O(n²) 或 O(n) | 均匀 | 标准 splice 版本移动元素，大数组性能差 |
| 原地交换洗牌法 | 每轮从未处理区间随机挑元素交换到边界 | O(n) | 均匀 | 实现细节容易写错边界 |
先记住这个结论，后面每一节都会解释为什么，尤其是为什么短代码不一定是好代码。
2. 实现一：排序随机法，代码最短但均匀性不达标
2.1 一行代码怎么写
排序随机法的写法非常短：
function shuffleBySort(arr) { return [...arr].sort(() => Math.random() - 0.5); }这里Math.random() - 0.5会得到一个大概在 -0.5 到 0.5 之间的数。负数表示比较时前一个元素要排在后面，正数表示前一个元素排在前。排序算法在不断比较元素的过程中调用这个随机比较器，最终得到一个看起来被打乱的顺序。
它适合什么场景？我的判断是：只适合“演示、临时调试、对公平性完全没有要求的小数据量展示”。比如你本机随手模拟一点测试数据，想快速让列表顺序变一变，用它没毛病。但凡是拿这个结果去做抽奖、做 AB 分组、做题库分配，我都建议你立刻换掉。
2.2 为什么随机比较器会带来偏差
问题出在它根本不是合格的比较器。排序算法在实现时默认比较器满足两个性质：一致性——如果 a 小于 b，那么任何一次比较中 a 都小于 b；传递性——如果 a 小于 b 且 b 小于 c，那么 a 必须小于 c。sort(() => Math.random() - 0.5)每次都比较同一个元素对，结果却可能完全不同，这在排序算法眼里就是数据自相矛盾。
你可能想问：就算比较器不守规矩，最终不也产生了一个排列吗？问题就在于，主流 JavaScript 引擎的排序实现会按照特定顺序访问元素，并依赖比较结果把元素分到左边或右边，随机比较器会让这个过程出现系统性偏向：有些元素更容易被放到某些位置，有些相对顺序更容易被保留。
举一个非常小的例子：对[1, 2, 3]做一万次sort(() => Math.random() - 0.5)洗牌，理论上一共有 6 种排列，每种出现概率是 1/6。但实测结果会发现，正序1,2,3和倒序3,2,1出现的频率明显高于理论值，中间的一些排列反而偏低。数字越多，偏差模式越复杂，但结论一致：它不是均匀乱序。
2.3 实跑数据与“能不能补救”
如果你想自己在浏览器控制台里复现，可以这样写：
const counter = {}; const source = [1, 2, 3]; for (let i = 0; i < 100000; i++) { const key = shuffleBySort(source).join(','); counter[key] = (counter[key] || 0) + 1; } console.log(counter);我在本地环境跑过一次，六种排列的占比并不是均匀落在 16.7% 附近，有的排列会冲到 20% 以上，有的会掉到 10% 以下。这个差距在抽奖系统里是完全无法接受的。如果业务方要求“概率公平”，排序随机法第一阶段就会被否掉。
那能不能补救？没有完美的补救方式，除非你不再依赖随机比较器。唯一的办法是换思路，用下面两种方法。所以这里不建议继续给sort版打补丁，直接换实现更干净。
还有一个连带问题：排序算法的比较次数和元素顺序有关，随机比较器会在一次排序里大量调用随机函数，而且调用次数不可预期。对性能的伤害不只是复杂度上的细微差异，而是随机数被浪费在一条不可控的排序路径上。
3. 实现二：逐个抽取法，最符合直觉的均匀乱序
3.1 splice 版本：先看最直白的写法
逐个抽取法的思路一句话：把原数组复制到“候选池”，每次从候选池里随机挑一个元素，放到新数组末尾，同时把它从候选池中删掉，直到候选池为空。
function shuffleByPick(source) { const pool = [...source]; const result = []; while (pool.length > 0) { const index = Math.floor(Math.random() * pool.length); const picked = pool.splice(index, 1)[0]; result.push(picked); } return result; }这段代码非常直观：候选池剩几个元素，下标范围就是 0 到pool.length - 1，Math.random()乘以pool.length后取整，得到的结果一定落在这个范围内。每抽出一个，池子长度减一，下一次随机范围也随之缩小。整个过程和现实中“从一摞牌里抽牌”一模一样。
3.2 抽签模型的均匀性推导
很多人直觉认为“先抽肯定占便宜，后抽吃亏”，其实不然。拿[A, B, C]举例：第一轮，A 被选到第一个位置的概率是 1/3。第二轮，A 想被放到第二个位置，前提是它第一轮没被选中（概率 2/3），然后在剩下的两个元素里被选到（概率 1/2），合起来是 2/3 × 1/2 = 1/3。第三轮同理。也就是说，A 出现在三个位置的概率都是 1/3。
更一般地，某个排列最终出现的概率是：
1/n × 1/(n-1) × 1/(n-2) × … × 1/1 = 1/n!
这正是完全随机排列的理论概率。所以单独看分布，逐个抽取法是绝对合格的，不存在排序随机法那种系统性偏斜。但它的代价也显而易见：splice每删一个元素，都要把后面所有元素往前挪。n 次循环加起来的搬移量是 O(n²)。对 100 个元素的数组完全无所谓，但到了 10000 个元素，每次删除都要移动成百上千个元素，浏览器里会肉眼可见地卡。
3.3 性能优化版：用交换代替 splice
有个经典的优化技巧：既然每次抽走元素后，我们只关心“剩余元素里随机挑一个”，完全没必要真的从数组里 splice。可以把被抽走位置的元素用当前数组最后一个元素补上，然后pop()收缩候选池。这样删除操作就是 O(1)。
function shuffleByPickFast(source) { const pool = [...source]; const result = []; while (pool.length > 0) { const j = Math.floor(Math.random() * pool.length); result.push(pool[j]); pool[j] = pool[pool.length - 1]; pool.pop(); } return result; }这段代码仍然保留了“逐个抽取”的语义：每一轮都在当前剩余集合里等概率抽一个元素。只是数组本身充当了可变的容器，顺序不再有意义。代价是需要额外理解一行“用最后一个元素补坑”的操作，不过它换来的 O(n) 复杂度是值得的。
到这里，抽取法的潜力已经发挥到极致。它需要额外开一个result数组，空间上做不到原地；下一节的原地交换洗牌法在这个思路上更进一步，把“抽出去”变成“交换到已确定区域”，连新数组都省了。
4. 实现三：原地交换洗牌法，项目里的标准答案
4.1 倒序版和正序版代码
原地交换洗牌法，是面试中多数人说的标准洗牌算法。倒序版是最常见的写法：
function shuffle(arr) { const result = [...arr]; for (let i = result.length - 1; i > 0; i--) { const j = Math.floor(Math.random() * (i + 1)); [result[i], result[j]] = [result[j], result[i]]; } return result; }每轮循环，我们把“尚未确定顺序”的区域视为[0, i]，当前位置i是这块区域的末尾。从 0 到 i 之间随机选一个下标 j，把 j 位置的元素和 i 位置元素交换。一轮结束后，i 位置上的元素就被固定了，不需要再参与后续随机。随着 i 从 n-1 一步步减到 1，所有位置都被随机覆盖一次。
如果不想拷贝原数组，可以改成原地直接打乱：
function shuffleInPlace(arr) { for (let i = arr.length - 1; i > 0; i--) { const j = Math.floor(Math.random() * (i + 1)); [arr[i], arr[j]] = [arr[j], arr[i]]; } return arr; }正向版本同样存在，写法是固定已经处理好的前缀，每次都从右侧未处理的区域随机选元素：
function shuffleForward(arr) { const result = [...arr]; for (let i = 0; i < result.length - 1; i++) { const j = i + Math.floor(Math.random() * (result.length - i)); [result[i], result[j]] = [result[j], result[i]]; } return result; }两个方向最终等价。倒序版写起来更短，因为Math.random() * (i + 1)直接给出[0, i]的整数范围；正序版需要额外加 i 来保证只从右侧未处理区取。代码风格上怎么选都行，关键是理解“未处理区”这个概念。
4.2 每一轮都等概率的正确性推导
简单推一下倒序版。第一轮，i = n-1，所有 n 个元素都在候选区，某个元素被选中放到最后一个位置的概率是 1/n。第二轮，i = n-2，候选区剩 n-1 个元素，某个元素能站到倒数第二个位置，需要它第一轮没被选中（概率 (n-1)/n），且第二轮被选中（概率 1/(n-1)），两者相乘得到 (n-1)/n × 1/(n-1) = 1/n。
每一轮计算下来，任意元素落在任意位置的概率都是 1/n。更进一步，由于每一轮选择都是对剩余集合的等概率抽样，整个过程生成每个全排列的概率正好是 1/n!，均匀性在数学上是完备的。
时间复杂度方面，单次循环内只有随机、交换两个常数操作，总复杂度 O(n)，额外空间只用了一个临时变量，属于真正的原地算法。对比排序随机法的 O(n log n) 和 splice 抽取法的 O(n²)，这是三种实现里唯一在复杂度上也“合格”的。
4.3 三个最容易写错的细节
写这个算法时，下面几个细节我几乎每次讲都能抓到人犯错。
第一，边界是i > 0而不是i >= 0。i 减到 0 的时候只剩一个元素和它自己交换，没有任何随机意义，纯粹浪费一次Math.random()。对结果无影响，但代码不干净。
第二，j的取值范围是 0 到 i（包含 i）。这一步非常重要，因为必须存在“这次不交换，当前元素留在原位”的概率。如果只取Math.random() * i，某个位置上的元素永远不可能留在自己位置，分布立刻出错。这是初学者最容易踩的坑。
第三，默认要不要拷贝入参。如果你在函数内部直接修改传进来的数组，调用方会在毫不知情的情况下丢失原始顺序。除非函数名明确叫shuffleInPlace，否则我建议默认用[...arr]拷贝一份，函数返回新数组，副作用最小。
4.4 用统计表验证你的实现
你不应该只在代码层面相信一个洗牌实现，最好用统计验证。下面是我常用的验证片段：
function checkUniformity(shuffleFn, size = 5, rounds = 200000) { const counts = Array.from({ length: size }, () => Array(size).fill(0)); const source = Array.from({ length: size }, (_, i) => i); for (let r = 0; r < rounds; r++) { const shuffled = shuffleFn(source); for (let pos = 0; pos < size; pos++) { counts[shuffled[pos]][pos]++; } } const expected = rounds / size; return counts.map(row => row.map(v => (v / expected - 1).toFixed(3)) ); }返回值是一个二维数组，里面每个数字等于“实际次数 / 理论次数 - 1”。数字越接近 0，说明该元素出现在该位置的频率越符合预期。抽样次数越多，结果越稳定。如果最后表里出现一列明显是正数、另一列明显是负数，基本可以判定洗牌实现有问题。
需要注意的是，任何基于Math.random()的算法在单次运行里都会有一定波动。不要拿着一两万次的结果就下结论，多跑几轮或者提高rounds到十万以上再看趋势。
5. 三种实现横向对比与最终选型建议
5.1 一表看清楚差距
| 维度 | 排序随机法 | 逐个抽取法 | 原地交换洗牌法 |
|---|---|---|---|
| 代码行数 | 1 行 | 约 6 行 | 约 4 行 |
| 时间复杂度 | O(n log n) | O(n²) 或 O(n) | O(n) |
| 空间复杂度 | O(n)（拷贝） | O(n)（额外数组） | O(n)（拷贝）或 O(1)（原地） |
| 排列均匀性 | 偏差明显 | 理论均匀 | 理论均匀 |
| 是否破坏原数组 | 否（拷贝） | 否（拷贝） | 看实现 |
| 适合规模 | 小数据、不敏感 | 中下规模 | 任意规模 |
| 可测试性 | 差 | 好 | 好 |
逐个抽取法如果采用“交换补坑”的优化，复杂度也能到 O(n)，但始终需要额外 result 数组；原地交换洗牌法在空间上更干净。三种实现想要做到理论均匀，本质都离不开“每一轮都在剩余元素中等概率选择”这个原则。排序随机法违反的恰恰是这一点。
5.2 哪些场景可以破例用排序随机法
虽然我很反对在生产环境用排序随机法，但必须承认有些场景它确实够用：比如后台系统里要临时调整几个记录的前后展示顺序、线下 Demo 想快速把一张表打乱、接口返回的数据本来就不需要均匀分布。这种时候图省事写一行，风险可控。
注意一个前提：不要在带公平比较、现金抽奖、分组实验、随机抽样统计的场景里用。抽奖逻辑如果把排序随机法写上去，运气不好会被业务方反复追问，最后还是要改。
有一个很稳妥的做法：如果怀疑未来会把 sort 版升级为正式版，那就从一开始直接用原地交换版，封装成独立函数，统一接收随机函数参数。代价不过多写三行，却彻底消除隐患。
5.3 让乱序可复现：随机种子与注入随机源
工程师迟早会遇到“这次乱序结果需要能复现”的需求，比如测试数据构造、分组回放、演示现场固定顺序。Math.random()每次调用不可预测，所以一个好习惯是让洗牌函数接收一个随机函数作为参数：
function shuffleWithRandom(arr, rand = Math.random) { const result = [...arr]; for (let i = result.length - 1; i > 0; i--) { const j = Math.floor(rand() * (i + 1)); [result[i], result[j]] = [result[j], result[i]]; } return result; }配合一个简单的种子随机函数，就能做到同一份输入、同一个种子，永远得到同一个排列：
function createSeededRandom(seed) { let state = seed >>> 0; return function () { state = (state * 1664525 + 1013904223) >>> 0; return state / 4294967296; }; } const shuffled = shuffleWithRandom(data, createSeededRandom(42));这个方案在单元测试里特别方便：你不需要改写全局Math.random，只需要在测试用例里传入固定种子，断言结果和期望的排列一致即可。
另外，如果你的场景是服务端抽奖、防作弊开奖这类，前端无论用什么洗牌都只是展示，真正决定结果的地方应该放在服务端，并使用安全性更高的随机数来源。前端领域不要尝试用Math.random()做任何对抗性场景，因为伪随机序列是可预测的。这一点不是本期文章要细讲的内容，但选型时一定要知道自己的能力边界。
5.4 我最终会写进代码库的版本
综合上面所有讨论，这是我个人在项目里默认使用的洗牌函数：
function shuffleRandom(arr, rand = Math.random) { const result = [...arr]; for (let i = result.length - 1; i > 0; i--) { const j = Math.floor(rand() * (i + 1)); [result[i], result[j]] = [result[j], result[i]]; } return result; }如果业务场景允许原地打乱，去掉拷贝，直接操作原数组即可。实际开发中，我还会加上一句注释，说明这是等概率的原地交换洗牌算法，防止后来者手一滑“优化”成sort(() => Math.random() - 0.5)。
数组乱序这个需求，看起来简单，实际上藏着算法一致性、复杂度、副作用管理三个层面的问题。今天把三种实现摆在一起对比之后，结论已经很清晰：默认选原地交换洗牌法，需要可复现时注入随机种子，涉及公平性场景时坚决绕开排序随机法。下次再有人递给你一段sort(() => Math.random() - 0.5)，你至少能说出它哪里不对了。
