随机密钥 / Salt
用 CSPRNG 按位长生成 Hex、Base64 或 URL-safe 密钥，可批量。
这个工具只做一件事：让浏览器自带的 CSPRNG（crypto.getRandomValues，操作系统的熵源）取若干个随机字节，再把它们换成便于搬运的文本。换算过程不引入额外随机性，也不丢失任何熵，熵等于位长本身，与输出用了多少字符无关。
和 UUID 不同，这里不保证唯一性，也不查询任何数据库：它保证的是「不可预测」。全部在浏览器本地完成，内容不上传、不联网，也不写入任何存储。
随机密钥 / Salt怎么用
- 位长与输出长度：位长 8–512、步长 8，所以字节数就是位长除以 8，输出长度可以口算：Hex 每字节 2 个字符，Base64 每 3 字节 4 个字符，URL-safe 同样但去掉补位。
- 按用途挑位长：会话令牌、签名密钥、加密密钥建议 256 位（32 字节）起步；Salt 与密码学 nonce 用 128–256 位；低于 128 位时页面会按错误级提醒，只适合校验值、分桶或测试占位。
- 按去处挑格式：要写进配置、日志、终端就选 Hex（最好读好 grep）；要塞进 JSON 或二进制紧凑存放选 Base64；会出现在 URL、查询串、文件名里选 URL-safe（-_ 且无 = 补位）。
- 批量与下载：条数填到 200，点「重新生成」再来一批，右下角「下载 .txt」把当前列表存下来，每行一条，方便直接导入配置。
常见问题
同一个 256 位密钥换成别的写法会变弱吗？
不会：256 位就是 2^256 种可能，换成十六进制是 64 个字符、换成 Base64URL 是 43 个字符，两者是同一个密钥的两种写法。工具下方的提示里会写明这一步的字符数与字母表大小。
能不能直接拿来当 API Key 发给用户？
随机体可以，但「用作 API Key」这件事还差一步：唯一性。常见写法是固定前缀（sk_live_、kc_、项目缩写）加随机体，前缀只用来标识来源、方便在日志里 grep 和按格式识别，不承担任何保密或随机性。本工具不与任何服务通信、也不查数据库，所以无法保证跨服务或跨时间不撞车——正式发号必须在服务端做：数据库唯一约束或主键、撞了就重试，或者用 UUID/ULID 承担可排序的唯一标识，再叠加这里的随机字节承担不可预测性。另外，密钥一旦写进数据库就该只存它的摘要（HMAC 或 Argon2），验证时比对摘要，别存明文。
为什么熵只看位长，不看输出有多少个字符？
因为字符只是表示法。1 字节的随机数写成 Hex 是 2 个字符、写成 Base64URL 是 2 个字符、写成十进制是 3 位数字，三种写法背后都是 8 位随机、256 种可能。反过来说，如果先固定「16 个字符」再去取随机字符，那才是真的在算熵：熵 = 字符数 × log2(字母表大小)。本页的输出走的是前一条路——先定字节再换算，所以字母表大小（16 或 64）只影响长度，不影响强度，提示里两个数都会写出来。
URL-safe、Base64、Hex 之间能互相还原吗？
能，因为它们描述的是同一串字节。URL-safe 还原成标准 Base64 只需把 - 换成 +、_ 换成 /，并按长度补回 = ；Base64 再解码成字节、每字节写两个十六进制字符就是 Hex。需要注意的是标准 Base64 里的 + 和 / 在 URL 里有特殊含义（+ 会被解成空格），放进查询串前必须转义或改用 URL-safe；而 Hex 只含 0-9a-f，任何上下文都不会歧义，代价是长度翻倍。
对应功能编号 #37无需安装，手机端同样可用按 Ctrl + K 换工具