UUID 在线生成器
免费的 UUID 在线生成工具，支持 UUID v4（随机）与 UUID v7（时间有序，2024 RFC 9562 新标准），可一次性批量生成最多 1000 个，提供大小写、无连字符、大括号等多种格式。基于 Web Crypto API 密码学安全随机数。
最后更新：
共 10 个 UUID · 使用 Web Crypto API crypto.getRandomValues 生成密码学安全随机数
UUID 各版本对比
| 版本 | 原理 | 是否有序 | 推荐场景 |
|---|---|---|---|
| v1 | 时间戳 + MAC 地址 | 部分 | 已不推荐，泄露 MAC |
| v3 / v5 | 命名空间 + MD5 / SHA-1 | 否 | 需要可重现 UUID 的场景 |
| v4 | 122 位随机 | 否 | 通用，但作为索引性能差 |
| v6 | v1 字段重排为可排序 | 是 | 从 v1 迁移 |
| v7 | 48 位毫秒时间戳 + 74 位随机 | 是 | 新项目首选，数据库主键 |
| v8 | 自定义实现 | 取决于实现 | 特殊定制（罕用） |
v6、v7、v8 由RFC 9562（2024 年 5 月发布）定义，取代原 RFC 4122。
各语言生成 UUID
| 语言 | UUID v4 | UUID v7 |
|---|---|---|
| JavaScript | crypto.randomUUID() | uuid v9+ 包的 v7() |
| Python | uuid.uuid4() | uuid7 包 / Python 3.13+ uuid.uuid7() |
| Java | UUID.randomUUID() | JDK 21 com.github.f4b6a3:uuid-creator |
| Go | uuid.NewRandom() | github.com/google/uuid v1.6+ NewV7() |
| Rust | Uuid::new_v4() | Uuid::now_v7() |
| PostgreSQL | gen_random_uuid() (v13+) | uuidv7() (v18+) / pg_uuidv7 扩展 |
| MySQL | UUID() 返回 v1 | 自实现或客户端生成 |
常见问题
UUID v4 和 v7 应该选哪个？
新项目优先选 v7。v4 是完全随机的 128 位，安全性最高但在数据库索引里因为乱序会导致 B+ 树频繁页分裂、写入性能差。v7 把前 48 位换成毫秒时间戳，剩下随机，仍然全球唯一且不可猜测，但天然按时间排序，作为主键时索引性能接近自增 ID。如果你的项目已经用 v4 没问题就不必迁移，新表建议直接上 v7。
UUID 真的全球唯一吗？会不会撞？
理论上有概率，实际可忽略。UUID v4 有 122 位随机性，要在 1 个组织里生成 10 亿条才有约 50% 概率出现一次重复。前提是用密码学安全的随机源（如本工具用的 crypto.getRandomValues）。用 Math.random() 实现的 UUID 是不安全的——质量差且可预测，绝不要在生产用。
UUID 作为数据库主键合适吗？
看场景：分布式系统、需要客户端预生成 ID、安全敏感（隐藏自增 ID 暴露数据量）—— 用 UUID v7。单库应用、写入密集、ID 不需要保密 —— 用自增 BIGINT 性能更好。MySQL 8 的 InnoDB 用 v7 比 v4 性能高 30%~50%。注意：MySQL 用 BINARY(16) 存比 CHAR(36) 节省 55% 空间。
UUID 和 Snowflake / ULID / NanoID 区别是什么？
Snowflake（Twitter）：64 位 long，时间戳+机器ID+序列，需要中心化分配 worker ID；ULID：128 位，前 48 位时间戳 + 80 位随机，Crockford Base32 编码（26 字符）；NanoID：可自定义长度的 URL-safe 短 ID，没有结构含义；UUID v7：RFC 9562 标准、JS/Java/Go 库支持广。新业务优先选 UUID v7（标准化最好）或 ULID（更短更友好）。
UUID 显示为大写还是小写？带不带连字符？
RFC 4122/9562 规定 UUID 字符串应小写并带连字符（8-4-4-4-12）。但解析时必须不区分大小写、可选连字符。一些场景例外：.NET 的 GUID 默认大括号、Windows 注册表常见 {大写}、URL 友好场景去掉连字符省 4 字节。本工具默认输出小写带连字符（最标准），其他格式按需切换。
为什么 UUID 不适合做短链或邀请码？
UUID 太长（36 字符）且看着像乱码，用户体验差。短链/邀请码建议用 NanoID（默认 21 字符，可配 8-12 字符）或自定义 Base62 短 ID。如果需要不可猜测+短，NanoID 比 UUID 更合适；如果可枚举（如自增数 + Base62 编码），别用 UUID。