crypto.getrandomvalues 比 math.random 更适合生成令牌，因其调用操作系统级 csprng，具备密码学安全性与不可预测性；而 math.random 是伪随机、可预测、无熵源保障。
crypto.getRandomValues 为什么比 Math.random 更适合生成令牌
Math.random 是伪随机数生成器，输出可预测、无熵源保障，浏览器甚至可能复用相同种子；而 crypto.getRandomValues 直接调用操作系统级 CSPRNG（如 Linux 的 /dev/urandom、Windows 的 BCryptGenRandom），通过硬件熵池混合，满足密码学不可预测性要求。它被设计为同步阻塞式调用，但实际在现代浏览器中几乎无延迟——别被“阻塞”二字吓住。
关键区别在于：你不是在“选一个随机数”，而是在“取一段加密安全的字节流”。
如何用 Uint8Array + getRandomValues 构建定长令牌
crypto.getRandomValues 只接受 Uint8Array（或 Int8Array 等视图）作为参数，不返回值，而是原地填充。常见错误是试图直接用它生成字符串——它只管字节，不管编码。
生成 32 字节令牌的正确流程：
- 先创建目标长度的
Uint8Array，例如new Uint8Array(32) - 传给
crypto.getRandomValues填充：crypto.getRandomValues(arr) - 再将字节数组转为字符串：推荐
Array.from(arr, b => b.toString(16).padStart(2, '0')).join('')（十六进制）或btoa(String.fromCharCode(...arr))（Base64，注意可能含+//和尾部=） - 若需 URL 安全 Base64（常用于 JWT、API token），用
arr.reduce((s, b) => s + 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-'[b % 64], '')或更稳妥地用Buffer.from(arr).toString('base64url')（Node.js）；浏览器端可用Array.from(arr, b => 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-'.charAt(b & 63)).join('')
示例（浏览器端 URL 安全 Base64 风格）：
function randomToken(len = 32) {
const arr = new Uint8Array(len);
crypto.getRandomValues(arr);
return Array.from(arr, b => 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-'.charAt(b & 63)).join('');
}
// → "aB3xK9mQvLpRtWzYcN2sFgHjUeI5oD7q"
常见报错和兼容性陷阱
最常遇到的是 TypeError: crypto.getRandomValues is not a function —— 这通常意味着当前上下文不是安全环境（Secure Context）。HTTP 页面、iframe 跨域、Service Worker 初始化阶段未完成等都会触发。
- 检查协议：必须是
https://或localhost（Chrome/Firefox 对localhost放宽） - 避免在非 secure context 的 iframe 中调用；可通过
self.isSecureContext判断 - Node.js 环境不提供全局
crypto.getRandomValues，应使用require('crypto').randomBytes(n)替代 -
crypto.getRandomValues不接受普通数组（[]）、ArrayBuffer（必须带视图），也不接受null或undefined - 某些旧版 Safari（Uint8Array 长度有上限（如 65536），超长需分批调用
为什么不要自己“增强” Math.random 的输出
有人尝试用 Math.random() 多次拼接、取时间戳、加鼠标位置再哈希——这毫无意义。哈希不能把低熵输入变高熵。crypto.getRandomValues 的价值不在“更乱”，而在“不可重现”。哪怕你调用一亿次 Math.random，只要知道初始种子，就能完全复现整个序列。
真正需要权衡的是：令牌长度是否足够抵抗暴力枚举（如 16 字节 hex 是 32 位，约 2¹²⁸ 空间），以及编码后是否适配使用场景（数据库字段长度、HTTP header 限制、URL 安全性）。这些跟“怎么生成”无关，只跟“生成多少字节”和“怎么编码”有关。
填错 Uint8Array 长度、忽略安全上下文、或在 Node.js 里硬套浏览器 API——这三个点，覆盖了 90% 的实际翻车现场。
