UUID 完整指南：v4 / v7 / Nano ID 怎么选
从 UUID 标准、版本差异，到 Nano ID 的优势、何时该用哪种 ID 生成方式，本指南给你结论。
系统中需要唯一 ID 时，从自增 ID 到 UUID 再到 Nano ID 有多种选择。每种各有优劣。本指南讲清楚什么场景该用哪一种、以及实际生成逻辑。
UUID 是什么
UUID（Universally Unique Identifier）是 128 位的标识符，习惯上写成 8-4-4-4-12 共 36 字符（含 4 个 -）的十六进制字符串：
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
碰撞概率：v4 每秒生成 10 亿个，连续 100 年才有 50% 概率撞一次。可以认为唯一。
v1/v3/v4/v5/v7 五种版本
- v1：基于时间戳 + MAC 地址。可逆推 MAC，不推荐，泄露隐私
- v3：基于命名空间 + 名字的 MD5（已废弃）
- v4：完全随机。最常用
- v5：基于命名空间 + 名字的 SHA-1。同样输入产生同样 UUID，适合幂等场景
- v7：时间戳前缀 + 随机后缀，单调递增。对数据库索引友好，2024 年正式标准化
现代项目优先选 v4 或 v7。
Nano ID
Nano ID 是 UUID 的轻量替代： - 默认 21 字符（vs UUID 36 字符），节省 40% 长度 - 字符集 64 个（A-Z a-z 0-9 _ -），URL 安全 - 可配置长度，碰撞概率自己算
何时选 Nano ID： - URL 中出现的 ID（如分享链接 example.com/p/abc123） - 不需要标准 UUID 协议兼容 - 想要更短的字符串
v4 vs v7（数据库索引视角）
v4 完全随机 → 每次插入都在 B+ 树随机位置，导致页分裂频繁、缓存失效。
v7 时间戳前缀 → 新 ID 总是接近最大值，单调递增插入，B+ 树几乎不需要重排。
实测在 MySQL InnoDB 上，v7 比 v4 写入快 30-50%。如果你的表会有几百万行 + 高频写入，v7 是更好选择。
何时不用 UUID
- 小表 + 单实例数据库：自增 BIGINT 更快、占空间小（8 字节 vs UUID 16 字节）
- 公开但不敏感的资源：用短链 + 自增 + Hashids 反而更紧凑
- 需要按时间排序：v1/v7 可，v4 不行
UUID 的真正优势：分布式生成、客户端预生成、跨表唯一。
常见问题
UUID 真的不会重复吗？
v4 每秒生成 10 亿个连续 100 年才 50% 概率重复。实际上你不需要担心。
GUID 和 UUID 是一回事吗？
是。Microsoft 把它叫 GUID，本质相同。
UUID 的版本号在哪里看？
第三段第一位字符：v1 = 1xxx, v4 = 4xxx, v7 = 7xxx。本工具会自动按你选的版本生成。