UUID生成器
在浏览器中批量生成UUID v4（随机）标识符。支持标准、大写、无连字符、大括号、URN等多种显示格式。
UUID版本一览
| 版本 | 生成方式 | 说明 |
|---|---|---|
| UUID v1 | 时间戳 + MAC地址 | 基于生成时间和网卡MAC地址生成。由于可能暴露生成设备信息而存在隐私隐患，目前新系统很少采用。 |
| UUID v3 | 命名空间 + MD5哈希 | 对命名空间和名称字符串进行MD5哈希后生成。具有确定性——相同输入始终得到相同UUID。由于MD5存在碰撞弱点，新用途推荐使用v5。 |
| UUID v4 | 完全随机 | 基于密码学安全的随机数生成。不包含来源信息，隐私性好且实现简单，是目前使用最广泛的版本。本工具生成的即为此格式。 |
| UUID v5 | 命名空间 + SHA-1哈希 | 与v3同样采用命名空间方式，但使用SHA-1。适用于需要确定性生成（相同数据始终得到相同ID）的场景。 |
| UUID v6 | 重排时间戳 + 随机数 | 2024年由RFC 9562标准化。重新排列了v1的时间戳字段，使字节序的字典顺序与时间顺序一致，从而提升数据库索引效率。 |
| UUID v7 | Unix时间戳 + 随机数 | 2024年由RFC 9562标准化。开头为毫秒精度的Unix时间戳，因此可按生成顺序排序。在新项目中作为v4的替代方案正被越来越多地采用。 |
使用提示
- 生成的UUID完全在浏览器内通过Web Crypto API处理，不会发送到toolbase.cc的服务器。
- 当需要唯一性但不想使用连续、可猜测的ID时（如数据库主键、API请求ID等），UUID v4是广泛使用的选择。
- UUID v4的128位中有122位是随机的，因此发生碰撞的概率极低（即使生成10亿个，碰撞概率达到约50%也需要约2.7×10¹⁸个）。
- "无连字符"格式便于用作URL路径段或文件名。"带大括号"格式与Windows COM/注册表中使用的GUID表示法相同。
- 增加生成数量后使用"复制全部"，可以方便地批量创建测试数据或种子数据。
常见问题
理论上并非绝对不可能，但由于UUID v4拥有122位随机性，实际使用中这种概率可以忽略不计。即使每秒生成10亿个UUID并持续100年，发生一次碰撞的概率也仅约为50%。
是的，基本上是同一个概念。GUID（全局唯一标识符）是微软对自身实现的称呼，与UUID的128位格式兼容。带大括号的格式
{xxxxxxxx-xxxx-...}是Windows COM/注册表中常见的GUID写法。由于UUID v4是随机的，相比连续整数（AUTO_INCREMENT），索引体积往往更大，插入性能可能下降。如果需要按插入顺序排序，可以考虑包含时间信息的UUID v7，或采用ULID作为替代方案。
如果只需要唯一性，UUID v4最简单且安全。如果需要相同输入始终得到相同ID，可选v5；如果新项目重视生成顺序或数据库插入效率，v7是有力选择。v1、v3目前已很少被新项目采用。
闲话 ― 为什么要用128位
UUID（通用唯一标识符）由Apollo Computer公司在1980年代为分布式系统而设计，后来由OSF（开放软件基金会）作为DCE（分布式计算环境）的一部分进行标准化。目前的规范见于IETF RFC 4122（2005年），2024年又发布了扩展版RFC 9562。
128位看似过多，但这个长度是为了保证多台服务器、设备完全不互相通信、各自独立发行ID时，在实际使用中也不会发生碰撞。若采用中央ID发行服务器统一管理连号，该服务器会成为单点故障，且每次发行都需要一次通信开销。UUID用足够长的随机性把碰撞概率降到可忽略的水平，从而彻底消除了这种协调成本。
但UUID v4正因为是随机的，插入数据库的B-Tree类索引时会导致插入位置分散，频繁引发页分裂，从而影响性能。为解决这个问题而设计出的可按时间顺序排序的UUID v7，通过在开头携带Unix时间戳，在保持随机性的同时确保了插入局部性。