ToolDeck 的 UUID 工具集将所有主流唯一标识符格式汇聚于一处。工具集包含：UUID v4 Generator，生成随机的密码学强度 ID；UUID v7 Generator，生成可按时间戳排序的主键；UUID v1 Generator，生成基于时间与 MAC 地址的标识符；UUID v2 Generator，适用于遗留 DCE 系统；UUID v3 Generator，生成基于 MD5 的确定性 ID；ULID Generator，生成紧凑的可排序字符串；NanoID Generator，生成短小的 URL 安全令牌；CUID Generator，原始抗碰撞格式；CUID2 Generator，其现代继任者；以及 UUID Decoder，用于检查现有标识符。所有工具完全在浏览器端运行，使用 Web Crypto API——不传输任何数据至服务器，无需账号。
什么是 UUID 与唯一 ID 工具？
UUID（通用唯一标识符）是一种 128 位标识符，已在 RFC 9562（原 RFC 4122）中标准化。以 8-4-4-4-12 格式的 32 个十六进制字符表示，例如：550e8400-e29b-41d4-a716-446655440000。该标准定义了多个版本，每个版本采用不同策略确保唯一性：随机数、时间戳或确定性哈希。
UUID 的设计初衷是让分布式系统无需中央协调器即可生成标识符。无论是在 PostgreSQL 中分配主键、在 Web 应用中生成会话令牌，还是在对象存储中命名文件，UUID 都能让系统中的每个节点独立创建全局唯一 ID——碰撞概率极低，在实践中可忽略不计。
在 UUID 标准之外，已涌现出多种替代唯一 ID 格式来解决特定限制：ULID 和 UUID v7 增加了字典序可排序性，提升数据库索引效率；NanoID 为 URL 和 Cookie 减小了体积；CUID2 针对客户端大批量生成场景，优先保障基于指纹的抗碰撞能力。
为什么要在 ToolDeck 上使用 UUID 工具？
ToolDeck 的 UUID 工具完全在浏览器端运行。没有 API 调用，没有服务端处理，不记录任何数据。每个生成器均使用 Web Crypto API（crypto.getRandomValues）提供密码学强度的熵——与浏览器用于 TLS 密钥材料的来源相同。
🔐密码学强度的熵
所有基于随机数的生成器（UUID v4、NanoID、CUID2）均使用 crypto.getRandomValues，而非 Math.random。输出适用于对安全性敏感的场景，如会话令牌和 API 密钥。
📦所有主流 ID 格式一站汇聚
UUID v1 至 v7、ULID、NanoID、CUID 和 CUID2——开发者所需的所有格式，支持批量生成和一键复制。
🔍解码并检查现有 ID
UUID Decoder 可从任意 UUID 中提取版本、变体、时间戳和节点字段。适用于调试、审计和理解代码库中的遗留 ID。
⚡零配置，支持离线使用
无需安装，无需注册，无运行时依赖。打开页面即可生成。所有工具在页面加载后均可离线使用——适合隔离环境或受限网络。
UUID 工具使用场景
唯一标识符出现在技术栈的每一层。以下是不同角色使用 UUID 生成工具的典型场景：
数据库主键
后端工程师将 UUID v4 或 UUID v7 用作 PostgreSQL、MySQL 和 MongoDB 的主键。UUID v7 的时间戳前缀使行在磁盘上保持物理有序，避免写入密集型工作负载下的页面分裂。
前端状态与组件 ID
前端开发者使用 NanoID 或 UUID v4 为动态创建的列表项生成稳定的 React key，为 ARIA 可访问性属性生成对话框 ID，以及为表单提交生成幂等令牌。
分布式事件流
在事件驱动系统中，每个事件都需要全局唯一且可排序的 ID。DevOps 和平台工程师使用 ULID 或 UUID v7，使 Kafka 消费者、日志聚合器和审计记录无需额外时间戳字段即可按创建时间排序。
测试数据生成
QA 工程师批量生成 UUID，以填充包含真实非连续 ID 的测试数据库。确定性的 UUID v3 或 v5 允许从已知输入重新生成相同 ID——适用于可重现的测试 fixture。
微服务关联 ID
将 UUID 附加到每个传入的 HTTP 请求并在服务调用中传播（X-Request-ID 请求头），让分布式追踪系统能够跨服务关联日志。UUID v4 是请求关联的事实标准。
资源与文件命名
对象存储（S3、GCS、Cloudflare R2）的键和 CDN 资源文件名通常嵌入 UUID，以防止缓存冲突和 URL 猜测。NanoID 的 21 字符紧凑格式相比完整的 36 字符 UUID 可缩短 URL 长度。
UUID 版本与格式参考
下表对比了所有 UUID 版本及最广泛使用的替代格式，帮助快速确定适合需求的方案。
| 标识符 | 算法 | 可排序 | 确定性 | 最适用于 |
|---|
| UUID v4 | 随机（CSPRNG） | — | — | 通用 ID、会话令牌、主键 |
| UUID v7 | Unix 毫秒时间戳 + 随机 | ✓ | — | 可排序主键、分布式事件 ID（RFC 9562） |
| UUID v1 | 时间戳 + MAC 地址 | ✓ | — | 按时间排序的 ID、单节点系统、遗留兼容性 |
| UUID v3 | 命名空间 + 名称 + MD5 | — | ✓ | 从已知输入（DNS、URL）生成可重现 ID |
| UUID v5 | 命名空间 + 名称 + SHA-1 | — | ✓ | 与 v3 相同但哈希更强；推荐 v5 优先于 v3 |
| UUID v2 | 时间戳 + DCE UID/GID | ✓ | — | 遗留 POSIX/DCE 环境；新项目请避免使用 |
| ULID | 时间戳前缀 + 随机 | ✓ | — | 可排序 ID，URL 安全，无连字符（26 字符） |
| NanoID | 随机（CSPRNG），URL 安全字符集 | — | — | 用于 URL、Cookie、HTML 属性的短 ID（21 字符） |
| CUID2 | 指纹 + 时间戳 + 随机 | — | — | 客户端大批量生成，抗碰撞能力强 |
UUID v3 和 v5 是确定性的：相同的命名空间 + 名称始终生成相同的 UUID。其他所有格式每次调用都会生成新值。
如何选择合适的 UUID 工具
合适的标识符取决于可排序性、大小和确定性需求。参考以下决策指南：
- 1
如果 需要无特殊要求的通用唯一 ID → UUID v4 Generator - 2
如果 需要按时间顺序排序且符合 UUID 标准的 ID → UUID v7 Generator - 3
如果 需要带嵌入式时间戳、按时间排序的 ID，适用于单节点或低并发系统 → UUID v1 Generator - 4
如果 需要 URL 安全、无连字符的可排序 ID → ULID Generator - 5
如果 需要比完整 UUID 更短的紧凑 URL 安全 ID → NanoID Generator - 6
如果 在客户端大批量生成 ID 且需要强抗碰撞能力 → CUID2 Generator - 7
如果 需要 CUID v1 格式以兼容基于原始规范构建的现有系统 → CUID Generator - 8
如果 需要从命名空间和名称确定性地重现相同 ID → UUID v3 Generator - 9
如果 使用需要 v2 标识符的遗留 DCE 或 POSIX 系统 → UUID v2 Generator - 10
如果 有现有 UUID 并需要检查其版本、变体或时间戳 → UUID Decoder
UUID v7 和 ULID 均提供毫秒精度的时间戳前缀和字典序可排序性。核心区别：UUID v7 使用标准 UUID 格式（8-4-4-4-12，36 字符），生态兼容性最佳；ULID 使用自定义 Base32 编码（26 字符，URL 安全，无连字符）。若数据库、ORM 或框架原生支持 UUID 列，优先选择 UUID v7；若需要更短的 ID 且无框架限制，ULID 更为紧凑。
常见问题
什么是 UUID？
UUID（通用唯一标识符）是 RFC 9562 标准化的 128 位值，以 32 个十六进制数字分五组用连字符隔开表示：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。标准定义了多个版本，各有不同的唯一性策略——随机（v4）、基于时间戳（v1、v7）或基于名称的确定性（v3、v5）。
UUID v4 和 UUID v7 有什么区别？
UUID v4 将 122 个非固定位全部用密码学安全来源的随机数据填充。UUID v7 在前 48 位编码 48 位 Unix 毫秒时间戳，后接随机位。结果：UUID v7 作为普通字符串即可按时间顺序排序，使数据库 B-tree 索引在插入时保持有序。UUID v7 在 RFC 9562（2024 年 4 月）中引入，是新建数据库主键的首选方案。
UUID v4 值是否具有密码学安全性？
UUID v4 值使用密码学安全伪随机数生成器（CSPRNG）生成，适合作为不可猜测的令牌——会话 ID、密码重置链接等。但 UUID 本身并非秘密：它没有 HMAC、没有过期时间、也不绑定到特定用户。应将 UUID 视为不透明标识符，而非身份验证凭据。
两个不同的系统可能生成相同的 UUID 吗？
UUID v4 的碰撞概率约为每对 1/2^122。要达到 50% 的碰撞概率，需要生成约 2.7 × 10^18 个 UUID——远超任何实际系统的产量。UUID v1 和 v7 还嵌入了时间戳和/或随机位，使意外碰撞更加不可能。就所有实际用途而言，来自不同系统的 UUID 不会碰撞。
为什么 UUID 有 36 个字符？
UUID 为 128 位 = 16 字节，以十六进制编码为 32 个字符。UUID 格式在固定位置（8、4、4、4 位十六进制数字组之后）添加 4 个连字符，以提升可读性并使版本和变体位一目了然，共 36 个字符。连字符不承载数据。
ULID 是什么？与 UUID 有何不同？
ULID（通用唯一字典序可排序标识符）是以 Crockford Base32 编码的 128 位标识符（26 字符，大小写不敏感，无连字符）。前 48 位编码 Unix 毫秒时间，后 80 位为随机数。ULID 作为普通字符串即可正确排序，且比 UUID 更紧凑。它不属于 UUID RFC 标准——使用不同的编码方式，也缺少 UUID 的版本/变体字段。
应该使用 UUID 还是自增整数作为主键？
自增整数顺序连续、紧凑、对索引友好，但需要中央协调器（数据库）来分配——在分布式系统中会失效，且会暴露行数。UUID（尤其是 v7 或 ULID）可在客户端无需数据库往返即可生成，支持乐观插入和分布式写入。代价是存储空间（16 字节 vs 4–8 字节）以及随机 UUID（v4）的索引局部性略差。UUID v7 和 ULID 通过时间戳前缀解决了索引局部性问题。
UUID v3 和 UUID v5 有什么区别？
UUID v3 和 v5 均为确定性：相同的命名空间 + 名称对始终生成相同的 UUID，适用于为 DNS 条目、URL 或对象标识符生成可重现 ID。唯一区别是哈希算法：v3 使用 MD5（128 位，已过时），v5 使用 SHA-1（160 位，截断为 128 位）。新项目建议使用 UUID v5——SHA-1 比 MD5 更强，尽管两个版本都不用于密码学哈希。