随机字符串生成

随机字符串生成器做的事很直接：你指定字符串的长度和允许出现的字符集（比如纯数字、大小写字母、十六进制、字母加数字混合），它就按规则生成一条或多条随机字符串。开发里经常需要这种「没有具体含义、只要够随机」的串——造测试数据要一批假的用户名或订单号，联调接口要临时的 token 或 session id，写脚本要一个随机文件名后缀或占位密码。手写 Math.random 拼一段、或者临时去翻库，都不如设好参数点一下来得快。支持批量生成后一次性复制走，省去逐条编造数据的重复劳动。

它的核心是「随机数到字符集下标」的映射：工具先确定候选字符集，得到一个字符数组，再为结果的每一位取一个随机数，对字符集长度取模（或按区间缩放）得到下标，取出对应字符拼接起来。随机数的来源决定了结果的质量——普通伪随机数（如 Math.random）足够应付测试数据和占位串，但它是可预测的，不适合当密钥或安全 token；浏览器的 crypto.getRandomValues 提供的是密码学安全的随机源，适合对不可预测性有要求的场景。十六进制模式本质上是把每 4 位映射到 0-9a-f，长度为 n 的十六进制串对应约 n×4 比特的取值空间，这也是为什么同样长度下十六进制的「熵」比纯数字高很多。判断一个字符集够不够用，看的正是「字符集大小的位数次方」有多大。

最常见的用法是造测试数据。比如要给数据库灌 500 条测试账号，用户名用「8 位小写字母加数字」批量生成 500 条，密码字段用「12 位混合字符」再生成一批，粘进 CSV 或 SQL 就能直接导入，不用一个个编。另一个高频场景是临时凭证：本地开发时给某个内部接口造一个 32 位十六进制的 mock token 塞进请求头，或者给上传的临时文件起一个随机后缀避免重名。像 A/B 测试的分组标识、消息队列里的幂等键占位、邀请码和验证码的样例，也都可以按位数和字符集一次配好、批量取用。

有几个容易踩的点。一是「随机」不等于「唯一」：位数太短、字符集太小时批量生成会撞车，比如 4 位纯数字总共才 1 万种可能，生成几百条就大概率重复，需要唯一性时要么加大长度和字符集，要么生成后自己去重。二是它和 UUID 生成器不是一回事——UUID 有固定格式和版本规范（如 v4 的 8-4-4-4-12 结构），提供概率上的全局唯一保证，随机字符串则是完全自定义长度和字符集的，更灵活但不带格式约定。三是要放进 URL、文件名或当 token 传输时，注意避开易混淆字符（0 与 O、1 与 l 与 I）和需要转义的符号，这类场景更适合十六进制或 Base62 这种 URL 安全的字符集。最后，真正当密钥、密码或安全 token 用时，别依赖普通伪随机结果，应确认随机源是密码学安全的，并配合足够长度保证熵。

随机字符串生成是一个免费的在线工具，打开网页就能用，不用下载也不用注册。平时大家搜的“随机字符串生成”、“随机字符串”、“随机码生成”，说的都是这个。