UUID 生成器与解析器

什么是 UUID？

// Generate a UUID v4 using the Web Crypto API
const uuid = crypto.randomUUID();
console.log(uuid);
// → '550e8400-e29b-41d4-a716-446655440000'

// Manual v4 generation with crypto.getRandomValues()
function generateUUIDv4() {
  const bytes = new Uint8Array(16);
  crypto.getRandomValues(bytes);
  bytes[6] = (bytes[6] & 0x0f) | 0x40; // version 4
  bytes[8] = (bytes[8] & 0x3f) | 0x80; // variant 10
  const hex = Array.from(bytes, b => b.toString(16).padStart(2, '0')).join('');
  return `${hex.slice(0,8)}-${hex.slice(8,12)}-${hex.slice(12,16)}-${hex.slice(16,20)}-${hex.slice(20)}`;
}

核心功能

UUID 版本对比

根据使用场景选择合适的 UUID 版本。

UUID 与其他 ID 格式对比

UUID 版本示例

550e8400-e29b-41d4-a716-446655440000

01906b5e-4a3e-7234-8f56-b8c12d4e5678

6ba7b810-9dad-11d1-80b4-00c04fd430c8

886313e1-3b8a-5372-9b90-0c9aee199e5d

使用方法

1. 1

   选择 UUID 版本

   从 v1（基于时间戳）、v3（MD5 命名）、v4（随机）、v5（SHA-1 命名）或 v7（时间排序随机）中选择。每个版本有不同用途——v4 是通用场景中最常用的版本。

2. 2

   配置选项

   对于 v3 和 v5，选择命名空间（DNS、URL、OID、X.500 或自定义）并输入要哈希的名称。设置生成数量（1 到 50），选择输出格式：标准小写、大写、无连字符或大括号 {GUID}。

3. 3

   生成 UUID

   点击「生成 UUID」按钮。每个 UUID 均使用 Web Crypto API（crypto.getRandomValues()）创建，确保加密安全性。版本特定字段（如 v1/v7 的时间戳和 v3/v5 的哈希值）会被正确编码。

4. 4

   复制使用

   点击任意 UUID 旁的「复制」按钮将其复制到剪贴板，或使用「复制全部」一次复制所有生成的 UUID。切换到「解析」标签页可分析现有 UUID 的版本、变体、时间戳和其他嵌入信息。

常见使用场景

数据库主键

使用 UUID v4 或 v7 作为唯一主键，无需数据库节点间的协调。UUID v7 尤其适合，因为其时间排序特性可提升 B-tree 索引性能。

分布式系统

在微服务、消息队列和事件溯源系统中独立生成唯一标识符。UUID 消除了对集中式 ID 生成服务的需求。

API 开发

为 RESTful 和 GraphQL API 创建唯一的请求 ID、关联 ID 和幂等键。UUID 使跨分布式服务边界的请求追踪变得简单。

会话与令牌管理

为认证流程生成唯一的会话标识符和临时令牌。UUID 提供足够的唯一性，防止大规模用户群中的会话冲突。

测试与开发

快速生成测试数据、模拟标识符和自动化测试所需的唯一固定 ID。批量生成功能便于填充开发数据库和测试套件。

技术细节

UUID 结构

UUID 为 128 位（16 字节），以 32 个十六进制字符按 8-4-4-4-12 格式表示。第 48–51 位（第 13 个 hex 数字）编码版本号。第 64–65 位编码变体字段，标识 UUID 的布局方式。其余位承载版本特定的有效载荷：时间戳、随机数据或哈希输出。

版本位

第 48–51 位（第 7 个字节的高半字节）编码 UUID 版本：0001 = v1（基于时间戳）、0011 = v3（MD5 命名）、0100 = v4（随机）、0101 = v5（SHA-1 命名）、0110 = v6（重排时间）、0111 = v7（Unix 纪元时间）。这四个位在生成时始终被显式设置。

变体字段

第 64–65 位（第 9 个字节的两个最高有效位）定义变体。模式 10x 表示 RFC 4122/9562 UUID（绝大多数）。模式 110 表示微软 GUID，采用混合字节序。模式 0xx 表示 NCS 向后兼容的 UUID（遗留）。模式 111 保留供将来使用。

RFC 9562 标准

RFC 9562 于 2024 年 5 月发布，取代 RFC 4122 成为权威的 UUID 规范。它正式引入了 UUID 版本 6、7 和 8。版本 6 重新排列 v1 字段以实现可排序性。版本 7 使用 48 位毫秒级 Unix 时间戳加随机数据，是新的基于时间的 UUID 的推荐版本。版本 8 为自定义的、实现特定的 UUID 提供格式。RFC 9562 还正式废弃了 v1，推荐使用 v6/v7 替代。

最佳实践

选择合适的版本

通用唯一标识符且不需要排序或确定性时使用 v4。数据库主键使用 v7——其时间排序特性显著提升索引性能。需要从名称派生确定性 ID 时使用 v5（优先选择 v5 而非 v3，因为哈希更强）。

数据库主键使用 UUID v7

UUID v7 的时间排序结构使 B-tree 插入保持顺序，与随机的 v4 UUID 相比减少约 90% 的索引碎片化。这意味着更快的写入、更小的索引和更好的缓存利用率。大多数现代数据库（PostgreSQL 17+、MySQL 8.0+）都有针对此模式优化的原生 UUID 支持。

切勿将 UUID 用作安全令牌

UUID 为唯一性而设计，非为保密性。UUID v1 会泄露生成时间戳和 MAC 地址。UUID v4 只有 122 位熵且结构可预测。对于安全令牌、API 密钥或会话密钥，请使用专用 CSPRNG 生成 128 或 256 位的纯随机数据，无需 UUID 结构的额外开销。

解析前先验证

在解析或存储之前，始终使用正则表达式验证 UUID 格式。在系统边界——API 端点、表单提交和数据库输入——拒绝格式错误的输入。这可以防止注入攻击、数据损坏以及无效标识符在系统中传播导致的难以调试的错误。

常见问题