随机不等于安全：用 Web Crypto API 构建前端真随机数生成器

一、前言：你的"随机"真的随机吗？

假设你在写一个抽奖转盘、一个扑克牌洗牌算法，或者一个密码生成器。你随手写下：

const luckyNumber = Math.floor(Math.random() * 100) + 1;

功能跑通，测试通过，一切都很美好。直到某天——

安全团队找上门："你们的随机数生成器可被预测。"

问题出在哪？ Math.random() 是一个伪随机数生成器（PRNG），种子源自浏览器引擎内部状态。理论上，攻击者只要能观测足够多的输出序列，就能逆向推演出后续的所有"随机"值。对于开奖、抽签、游戏等涉及利益的应用场景，这是不可接受的。

解决方案：Web Crypto API。

现代浏览器提供了 window.crypto.getRandomValues()，它从操作系统级别的真随机源（如 /dev/urandom、硬件熵源）获取随机性，具备"密码学安全"（CSPRNG）级别的不确定性。本文就带你从零构建一个生产级的安全随机数工具，并顺势聊一个实用的性能优化模式——随机数池（Random Pool）。

---

二、技术选型：为什么是 Web Crypto？

方案	特点	适用场景
Math.random()	快，但伪随机，不可控种子	动画、游戏特效等非安全场景
crypto.getRandomValues()	密码学安全，硬件熵源	抽奖、加密、Token 生成
第三方库（如 uuid）	封装好，但引入依赖	看项目体量，能省则省

结论：前端但凡涉及"安全"二字，就用 crypto.getRandomValues()。 而且它是浏览器原生 API，零依赖，兼容性覆盖 IE11+。

---

三、核心代码深度解析

3.1 安全的"公平骰子"：带偏差消除的随机整数生成

先看最核心的函数——生成一个 [min, max) 区间内的安全随机整数：

function getSecureRandomInt(min, max) {
  if (min >= max) throw new Error('最小值必须小于最大值');

  const range = max - min;
  // 计算需要多少字节来表示 range
  const bytesNeeded = Math.ceil(Math.log2(range) / 8);
  // 计算"公平截断点"
  const cutoff = Math.floor((256 ** bytesNeeded) / range) * range;

  const randomBytes = new Uint8Array(bytesNeeded);

  while (true) {
    window.crypto.getRandomValues(randomBytes);

    // 将字节数组拼接成一个整数
    let randomValue = 0;
    for (let i = 0; i < bytesNeeded; i++) {
      randomValue = randomValue * 256 + randomBytes[i];
    }

    // 只在随机值落在"公平区间"时返回，否则重试
    if (randomValue < cutoff) {
      return min + (randomValue % range);
    }
  }
}

这里藏着几个关键设计决策：

① 不需要每次都生成 4 字节的数组

getRandomValues 需要一个 TypedArray 作为容器。很多人会习惯性地创建 Uint32Array，但假如 range 只有 100，多出来的字节就是浪费。bytesNeeded 按需计算，最少 1 字节，最多......看你的 range 有多大。

② 拒绝采样消除模偏差（Modulo Bias）

这是整个函数里最大的坑，也是最不该省的一行代码。

试想一个简单方案：

// 有偏差的写法——不要这样做！
const randomValue = randomBytes[0];
return min + (randomValue % range);

问题在哪？一个字节的范围是 0–255，共 256 个值。如果 range = 100，0–55 这 56 个数各对应 3 个输入值（概率 3/256），而 56–99 各对应 2 个输入值（概率 2/256）。小数字更"幸运"，分布不是均匀的。

cutoff 的计算方式就是找到 256 以内最大的 range 的整数倍，落在 [cutoff, 256) 范围内的随机值直接丢弃、重新骰。这样就保证了 randomValue % range 时每个输出值对应完全相同的输入值数量，分布严格均匀。

一句话：cutoff 是一张"滤网"，滤掉了会让分布不均的"坏值"。

③ while(true) 会死循环吗？

理论上不会。即使是最坏情况（如 range = 129），cutoff = 128，每次有 (256 - 128) / 256 = 50% 的概率重试。期望重试次数 ≈ 1 / 接受率 ≈ 2 次。

实际上对于大多数 range，接受率都在 90% 以上，while 循环几乎不会触发。

---

3.2 "随机数池"模式：一次补货，随用随取

直接调用 crypto.getRandomValues() 有开销——毕竟是系统调用级别的操作。如果你的场景需要高频获取随机数（比如连续开 100 次奖），每次都桥接系统调用显然不划算。

随机数池的思路很简单：

┌──────────────────────────────────┐
│         随机数池 (Array)          │
│  [42, 17, 89, 3, 76, ...]        │
└──────────────────────────────────┘
        ▲  refillPool() 补充      │ useRandomNumber() 取走 (pop)
        │                         ▼
   getSecureRandomInt()     调用方拿到一个随机数

// Vue 组件中的使用
data() {
  return {
    randomPool: [],
    poolMin: 1,
    poolMax: 100,
    poolSize: 100
  }
},

mounted() {
  this.refillPool()  // 初始化时先灌 100 个
},

methods: {
  refillPool() {
    for (let i = 0; i < this.poolSize; i++) {
      this.randomPool.push(getSecureRandomInt(this.poolMin, this.poolMax))
    }
  },

  useRandomNumber() {
    // 池子见底了？自动补货
    if (this.randomPool.length === 0) {
      this.refillPool()
    }
    return this.randomPool.pop()
  }
}

这个模式有 3 个好处：

1. 性能预缓冲：一次性生成 100 个随机数，然后从数组中 pop()——O(1) 操作，比每次调 crypto.getRandomValues() 快几十倍。
2. 透明补货：调用方完全不感知池子的存在——没货了自动进货，API 简洁。
3. 可配置的平衡点：poolSize 越大越"懒"（批处理开销更低），但首屏初始化也越慢。100 是个经验上不错的默认值。

---

四、踩坑指南

坑 1：min 和 max 边界混淆

getSecureRandomInt(1, 100)  // 返回 [1, 100) → 即 1 到 99

函数中 range = max - min，最终 min + (randomValue % range)。取模的结果范围是 [0, range)，加上 min 后是 [min, max)。这是一个左闭右开区间。 如果你需要 [1, 100] 的闭区间，应该传 getSecureRandomInt(1, 101)。

坑 2：Uint8Array 的整数拼接

randomValue = randomValue * 256 + randomBytes[i];

这是用纯算术的方式把字节数组拼成一个大整数。为什么不直接用位运算 << 8 |？因为 JavaScript 位运算限制在 32 位有符号整数，一旦 range 很大（超过 2³²），位运算会溢出。乘法版本没有这个限制，可以支持任意大的范围。

坑 3：pop() vs shift()

原代码注释写的是"拿第一个数"，实际用的是 pop()。pop() 取的是数组末尾的元素，时间复杂度 O(1)；shift() 取数组头部，时间复杂度 O(n)（因为所有后续元素要前移）。所以 pop() 是正确的选择——在不需要 FIFO 的语义下，数组末尾操作性能最优。

---

五、总结与思考

核心要点：

• 安全场景（抽奖、加密、Token）必须使用 crypto.getRandomValues()，别碰 Math.random()。
• 拒绝采样是消除模偏差的经典手段，cutoff 那一行不是可选优化，是必要防线。
• 随机数池将"生成"和"消费"解耦，既保持安全性，又提升了高频调用下的性能。

进一步优化方向：

1. Web Worker 异步补货：把 refillPool() 移到 Worker 里，避免补货时短暂阻塞主线程。
2. 按需唤醒：当池子降到阈值（如 < 20）时触发后台补货，而非等完全见底再同步生成。
3. 泛型化：把池子抽象为 RandomPool 类，支持「均匀整数池」「洗牌后的扑克牌池」「UUID 池」等多种形态。

---

前端随机性，从熵开始。