← 返回博客

比 UUID 更短的 ID 方案：ULID、NanoID 对比

2026-04-15 · 5 分钟阅读

UUID 的局限性

UUID 虽然被广泛使用，但在某些场景下存在明显不足：长度（36 字符或 32 字符无连字符）在 URL 中不够优雅；UUID v4 没有时间顺序，数据库索引性能较差；不适合作为对用户展示的短 ID（如订单号、邀请码）；全小写十六进制字符串不够直观，可读性差；在某些对字段长度敏感的场景（如短信、二维码内容），36 字符过长。以下几种替代方案在特定场景下比 UUID 更合适。

ULID：可排序的 UUID 替代方案

ULID（Universally Unique Lexicographically Sortable Identifier）是解决 UUID 排序问题的优秀方案：26 字符（Crockford Base32 编码），比 UUID 的 36 字符更短；包含 48 位毫秒时间戳 + 80 位随机数，按生成时间自然排序；字母表仅使用 A-Z 和 0-9（排除易混淆的 I、L、O、U），URL 安全；单调递增保证：同一毫秒内生成的多个 ULID 仍然保持顺序；示例：01ARZ3NDEKTSV4RRFFQ69G5FAV。ULID 特别适合用作数据库主键，同时保留了良好的可读性。

NanoID：更短更快的随机 ID

NanoID 是一个轻量级随机 ID 生成库，默认生成 21 字符的 URL 安全 ID（使用 A-Za-z0-9_- 字母表）。与 UUID v4 相比：更短（21 vs 36 字符），URL 安全（无连字符问题），生成速度更快（约 2 倍），文件体积极小（JavaScript 包仅 108 字节）。NanoID 可以自定义长度和字母表，适合需要灵活 ID 长度的场景。例如：生成 10 位 ID 用于短链接，生成 6 位数字 OTP 码。注意 NanoID 没有时间顺序，不适合用作数据库主键（同 UUID v4）。

Snowflake ID：Twitter 的分布式 ID 方案

Snowflake 是 Twitter 开源的分布式 ID 生成算法，生成 64 位整数 ID：1 位符号位（固定为 0）、41 位毫秒时间戳（约 69 年）、10 位机器 ID（最多 1024 台机器）、12 位序列号（每毫秒最多 4096 个）。Snowflake ID 的优势：整数类型，存储和索引效率最高；严格有序（单节点单毫秒内 4096 个有序 ID）；可解码，从 ID 中提取时间戳、机器 ID 和序列号；缺点：需要协调分配机器 ID（中央协调问题），时钟回拨会导致 ID 重复（需要特殊处理），不如 UUID 通用。Snowflake 适合对性能要求极高、有中央协调能力的场景。

各方案代码示例

# ULID (Python)
# pip install python-ulid
from ulid import ULID
ulid = ULID()
print(str(ulid))  # 01ARZ3NDEKTSV4RRFFQ69G5FAV

# NanoID (Python)
# pip install nanoid
from nanoid import generate
id = generate()                   # 21 字符默认
short_id = generate(size=10)      # 10 字符
numeric_id = generate('0123456789', 6)  # 6 位数字

// NanoID (JavaScript)
// npm install nanoid
import { nanoid, customAlphabet } from 'nanoid';
console.log(nanoid());            // 21 字符
console.log(nanoid(10));          // 10 字符

const numeric = customAlphabet('0123456789', 6);
console.log(numeric());           // 6 位数字 OTP

// UUID v7 (最新标准，兼具时序性)
// npm install uuid
import { v7 as uuidv7 } from 'uuid';
console.log(uuidv7()); // 有时序的 UUID，格式同 UUID v4

选择指南：何时用哪种 ID

立即免费使用相关工具

免费使用 →