NanoID 是什么:比 UUID 更短的短 ID 生成方案

写后端的人迟早会碰到一个问题:给一条数据起个对外的唯一标识,用什么好。自增整数会泄露规模,别人看到 /orders/1042 就知道你有大约一千个订单,还能顺手去翻 /orders/1043。UUID 倒是够随机,但它有 36 个字符,带 4 个连字符,塞进 URL 又长又难看。NanoID 就是冲着这个空档来的。

NanoID 是什么

NanoID 是一种现代的唯一 ID 生成算法,核心就两件事:用密码学安全的随机源取字节,再用一张字母表把字节映射成字符。它没有版本位、没有变体标记,每一个字符都是纯随机的。默认配置是 21 个字符,配一张 64 字符的 URL 安全字母表(A-Za-z0-9 加上 _ 和 -)。

这套默认值携带 126 位熵。作为对比,UUID v4 把 128 位里的 6 位拿去当版本和变体标记,真正随机的只有 122 位。也就是说,默认 NanoID 的随机性其实比 UUID 还略多一点,字符却少了一大截。

为什么比 UUID 更短还更 URL 安全

短和安全在这里并不矛盾,关键在于每个字符携带多少位。十六进制每个字符只表示 4 位,所以 UUID 的 128 位需要 32 个 hex 字符才装得下,再加 4 个连字符,凑成 36。而 64 符号的字母表每个字符携带 6 位,21 个字符就是 21 × 6 = 126 位。

更省字符之外,NanoID 的字母表本身就是 URL 安全的,不含 / + = 这类需要转义的符号,也没有连字符去切断双击选词。生成出来的 ID 能直接拼进路径,不用再做一遍百分号编码。如果你正纠结要不要继续用 UUID,可以去 /zh/t/uuid-generator/ 生成几个对比一下长度和观感,差别一眼能看出来。

碰撞概率到底有多低

很多人对短 ID 的第一反应是怕撞车。这个担心可以用数学回答,不用靠感觉。设字母表大小为 A、长度为 L,总键空间就是 N = A 的 L 次方。在碰撞概率达到 p 之前你能生成的 ID 数量,大约是 n ≈ √(2 · N · ln(1 / (1 − p))),对 1% 这种小概率可以简化成约 √(2 · N · p)。

代进默认值:64 字符字母表、21 长度,键空间大到 10 的 37 次方量级。哪怕你每秒生成一百万个 ID,要让碰撞概率爬到 1%,也得跑上几百年。所以默认 NanoID 在实务里可以当作不会撞。工具里的碰撞面板会实时显示熵的位数、总键空间、约 1% 碰撞所需的 ID 数,你不用自己掏计算器。

自定义长度和字母表

NanoID 真正灵活的地方是这两个参数都能自己定。长度可以从 2 调到 256,字母表可以选预设(URL 安全、纯数字、小写、十六进制),也可以粘自己的一套。

最实用的自定义场景是免混淆的优惠码。打在小票上的码会被人重新敲一遍,O 和 0、l 和 1 就成了客服噩梦。这时把字母表换成 ABCDEFGHJKLMNPQRSTUVWXYZ23456789(去掉 O、0、I、1、l),长度设 8,生成出来的码人工录入不会出错。要注意字母表越小,达到同样的熵就需要越长的 ID,这正是碰撞面板帮你权衡的地方。

我自己上次给一个内测系统做邀请码,就是这么配的:32 字符字母表加长度 8,面板告诉我约有 40 位键空间,做几十万个码绰绰有余,于是没有盲目加长度。一个生成出来的样子是这样:

输入:URL 安全字母表 + 长度 21 + 数量 1
输出:V1StGXR8_Z5jdHi6B-myT

拿来做 URL 短 ID

把上面几点串起来,就是 NanoID 最常见的用法:做对外的短 ID。做法是自增主键留在内部,另加一列 public_id,默认值用 NanoID。字母表选 URL 安全、长度设 12(约 72 位熵,做单表公开句柄足够),URL 就从 /orders/1042 变成 /orders/V1StGXR8_Z5j,既猜不出来又短到能塞进一条推文。

如果你需要的是给文章标题做可读的 URL 路径,那是另一类需求,可以看 /zh/t/slug-generator/;而要生成 NanoID 本身,直接用 /zh/t/nanoid-generator/,所有计算都在浏览器本地完成,ID 不会发到任何服务器。

小结

NanoID 把"短"和"安全"这对看起来冲突的需求一起满足了:默认 21 字符携带 126 位熵,比 UUID 短了 15 个字符却更随机,字母表天生 URL 安全,还能按场景自定义长度和字母表。下次再纠结对外 ID 用什么,先把碰撞概率算清楚,再决定砍到多短,这比凭感觉拍长度靠谱得多。

Made by Toolora · Updated 2026-06-13