math.random()生成[0,1)浮点数，需配合math.floor()等取整才能得指定范围整数；推荐公式为math.floor(math.random()*(max-min+1))+min，可等概率覆盖闭区间[min,max]。
Math.random() 生成的是 [0, 1) 的浮点数，不是整数
很多人一上来就写 Math.random() * 10，以为能得到 0–10 的整数，结果发现：它返回的是小数，而且永远取不到 10（因为 Math.random() 最大只接近 1，不包含 1）。要得到整数，必须配合 Math.floor() 或 Math.ceil()，但选哪个、怎么加减，直接决定边界是否正确。
关键逻辑是：先拉伸区间，再平移起点，最后取整。比如要 [5, 12] 的整数（含两端），步长是 1，总共有 8 个可能值（12 − 5 + 1 = 8），所以得乘以 8，再加 5：
Math.floor(Math.random() * (12 - 5 + 1)) + 5
-
Math.random() * (max - min + 1)把范围拉到 [0, max−min+1) -
Math.floor(...)向下取整，得到 [0, max−min] 的整数（共 max−min+1 个） - 再加
min，整体平移到 [min, max]
为什么不用 Math.round() 或 Math.ceil()？
Math.round() 会让两端概率减半——比如 Math.round(Math.random() * 2) 生成 0/1/2，但 0 和 2 只在 [0, 0.5) 和 [1.5, 2) 区间出现，各占 1/4 概率；1 却占 1/2。而 Math.ceil() 在 [0,1) 上返回 0（错误），且无法自然覆盖下界。
- 用
Math.floor()是最稳妥的，能保证每个整数等概率、边界闭合 - 如果硬要用
Math.ceil()，得写成Math.ceil(Math.random() * (max - min)) + min，但此时Math.random() === 0会返回min，而Math.random()极小值可能导致结果不稳定，不推荐 -
Math.trunc()行为和Math.floor()在非负数时一致，但没必要换，可读性反而下降
封装成可复用函数时要注意参数顺序和校验
常见误写是把小值放后面，比如 randomInt(10, 1) 期望得到 [1,10]，但没做大小判断就会出错。实际使用中建议默认按「最小、最大」传参，并做基础防御：
function randomInt(min, max) {
if (min > max) [min, max] = [max, min];
return Math.floor(Math.random() * (max - min + 1)) + min;
}
- 不校验是否为整数——JS 中传入小数如
randomInt(1.7, 5.2)会得到 [1,5]，属合理隐式转换 - 不处理
NaN或非数字——调用方应负责输入质量，函数保持轻量 - 若需严格整数入参，可加
Number.isInteger(min) && Number.isInteger(max)判断，但多数业务场景不需要
ES2024 新增的 crypto.randomUUID() 不适用，crypto.getRandomValues() 太重
crypto.randomUUID() 生成的是 UUID 字符串，和数值随机无关；crypto.getRandomValues() 虽然更安全，但需要构造 Uint32Array，再手动映射到目标区间，对普通业务属于过度设计。
- 前端表单、动画、抽样展示等场景，
Math.random()完全够用 - 只有密码学用途（如生成密钥、token）才必须用
cryptoAPI - 注意：
Math.random()在 V8（Chrome/Node.js）中已改为基于 xorshift128+ 算法，质量和性能都足够日常使用
真正容易被忽略的是：不要在循环里反复调用 Math.random() 做条件重试（比如“直到不等于上一个值”），这会引入不可预测的延迟和偏差；有状态需求时，应该预生成数组或用 LCG 手动控制序列。
