Math.random()不能直接用于抽奖，因其无防重、分布偏差、无权重控制、无法匹配动画节奏；需封装为索引映射、累积概率匹配或动画阶段分离三类方案，并注意兼容性与浮点精度陷阱。
Math.random() 本身不依赖抽奖逻辑，但所有基于它的抽奖实现都必须主动处理它固有的缺陷——比如重复、分布偏差、不可控节奏、缺乏权重控制。直接拿 Math.random() 当“抽奖函数”用，等于把随机性交给浏览器引擎裸跑，结果往往和预期差很远。
为什么 Math.random() 不能直接当抽奖用
它只返回一个 [0, 1) 区间的浮点数，没有任何上下文约束：
- 连续调用可能产生相同值（尤其在高频
setInterval中），导致“连中同一奖”或“跳过某奖” - 用
Math.floor(Math.random() * n)生成0到n-1整数时，若n不是 2 的幂，底层浮点精度会引入微小但可测的分布倾斜 - 没有内置防重机制，也没法表达“一等奖概率 1%，谢谢参与 94%”这类业务规则
- 无法与 DOM 动画节奏对齐——比如九宫格高亮轮播时，你得控制“每 120ms 切一次”，但
Math.random()自己不会等你
Math.random() 在抽奖中怎么安全落地
关键不是“能不能用”，而是“在哪一层用、怎么封装”。常见做法分三类：
-
纯索引映射：适合固定奖品池且概率均等，如
prizes[Math.floor(Math.random() * prizes.length)]；但必须确保prizes非空，否则length为 0 会导致NaN -
累积概率匹配：用
Math.random()生成基准值，再遍历加权数组比对，例如：const r = Math.random();<br>let sum = 0;<br>for (const p of prizes) {<br> sum += p.probability;<br> if (r <= sum) return p;<br>}注意prizes的probability总和必须 ≈ 1（允许1e-10级误差） -
动画阶段分离：视觉轮播用计时器驱动（如
setInterval+ 索引自增），仅在最后一帧用Math.random()定格结果，避免用户看到“假随机”过程
容易被忽略的兼容性坑
这些细节不报错，但会让抽奖在某些场景失效：
立即学习“前端免费学习笔记（深入）”；
-
Math.random()在 Safari 15.4+ 和 Chrome 100+ 中已支持crypto.getRandomValues()替代方案，但旧版 iOS WebView 仍存在种子复用问题——同一秒内多次调用可能返回相同序列 - 如果抽奖按钮绑定的是
onclick="xxx()"行内事件，而逻辑里又用了document.getElementById，务必确认 DOM 已就绪，否则返回null导致后续.innerHTML报错 - 用
parseInt(Math.random() * n)代替Math.floor是危险的：当Math.random()返回0.9999999999999999，乘以n=8得7.999999999999999，parseInt截断后是7，看似没问题，但一旦n较大（比如 100000），浮点误差可能让结果溢出或归零
真正卡住人的从来不是 Math.random() 写不对，而是没想清楚：这个随机值到底该在哪个环节介入、是否要隔离动画与结果、有没有业务规则需要兜底校验。轮播十次停在第 7 格，和“按概率抽中三等奖”，是两件事——前者靠计时器和索引，后者才真正需要 Math.random()。
