← 全部工具
数据不出浏览器
UUID Generator — 在线生成
免费 UUID generator。一键生成 RFC 4122 版本 4 UUID，可批量复制。
- 63c26ce6-fc6c-4aef-b315-819f018ac921
- 4cddd3f1-fc9d-4c81-a402-17c690121fd7
- 1a43654c-14a5-4354-84d4-5ce0916dd03d
- 19f63728-ba60-4c8a-9931-41ac9a804842
- c6eb6305-e782-42ad-9801-86797e2c3f06
选对 UUID 版本
UUID 版本的重要性常被低估，因为它决定了数据库索引长什么样。完全随机的 v4 会散落到 B 树各处，造成索引碎片，写入密集的表越大越慢。时间有序的 v7 同样全局唯一，但随时间递增，插入位置靠近索引末尾，行为更接近自增整数。
当标识符需要在多个地方独立生成、无需协调时，或者当自增整数会泄露信息（例如你累计了多少订单）时，UUID 是对的。而当标识符要出现在人们会阅读的 URL 里时，它就不太合适——36 个字符既难输入也难记住。
有一点必须说清：UUID 不是密钥。v4 的随机性足够强，猜中一个并不现实，但 UUID 会被大量写日志、建索引、四处传递，而且没有有效期和吊销机制。凡是能授予访问权限的东西，都应当是有自己生命周期的凭据，而不是复用一个标识符。
常见问题
- 什么是 UUID？
- 通用唯一标识符，广泛用于数据库主键与分布式系统。
- v4 是随机的吗？
- 是。v4 使用密码学安全随机数。
- 会冲突吗？
- 理论上可能，但概率极低，实际可忽略。
- 该用 UUID v4 还是 v7？
- 新的数据库主键用 v7，因为它的时间前缀让插入保持顺序、索引更健康。当值本身不能暴露创建时间，或者只生成一次、几乎不重写（例如日志里的请求 ID）时，用 v4。
- UUID 适合做主键吗？
- 只要接受存储成本就可以：16 字节，索引比 4 字节整数宽，外键也更占空间。真正的性能问题来自随机性而不是体积，这正是时间有序版本存在的原因，也是纯 v4 方案在规模上去之后往往需要返工的原因。
- 可以用 UUID 当 API token 吗？
- 不建议，即使 v4 的随机性够强。token 需要有效期、作用域、轮换和吊销，而 UUID 一个都没有。请用专门的 CSPRNG 生成凭据，并只保存其哈希，这样数据库泄露也不会直接送出可用权限。