UUID生成器：在线生成UUID v4唯一标识符（可批量，2026）

下面这个uuid生成器工具，纯浏览器本地运行，即时出结果不上传数据。往下有原理和使用说明。

UUID 是什么，这个工具帮你解决什么

UUID 是一串 128 位的唯一标识符，不依赖中央数据库分配，就能让分布式系统各自生成、几乎绝不重复的 ID。上面的工具在你浏览器本地生成标准 UUID v4，支持一次批量出几十上百条、一键复制或导出，全程不联网、不上传服务器，做测试数据、填数据库主键、给对象命名都能直接拿去用。

原理：128 位里，122 位是纯随机

UUID v4 的做法很直接——除去用来标记「版本」和「变体」的 6 个固定比特，剩下 122 位全部由密码学随机数填充。它不看时间、不看机器网卡，纯靠随机性来避免碰撞。标准写法是 8-4-4-12 的十六进制分组，比如 f47ac10b-58cc-4372-a567-0e02b2c3d479：其中第 13 位固定是 4（版本号），第 17 位只会是 8、9、a、b 之一（变体位），这也是肉眼分辨一条 UUID 是不是 v4 的最快办法。规则出自 IETF 2024 年发布的 RFC 9562，它已取代沿用二十多年的旧标准 RFC 4122。

什么场景该用它

凡是「多个节点各自造 ID，又不能撞车」的地方，UUID 都是默认选择：微服务里给每个请求打链路追踪 ID、前端在没拿到后端主键前先占位、消息队列做幂等去重、文件与对象存储的命名、数据库合并时避免自增主键冲突。它的最大好处是离线也能生成——不用先问数据库要一个号，这在移动端弱网、边缘计算、多主写入场景里尤其关键。反过来，如果你只是给单库单表做主键、又特别在意索引性能，那 v4 的「完全无序」会拖慢 B+ 树写入，这时更该看下面表格里的 v7。

选版本：v1、v4、v7 怎么挑

RFC 9562 新增的 v7 是这两年的热点：它把毫秒级时间戳放在高位，天然按生成顺序递增，既保留了随机性防碰撞，又解决了 v4 插入乱序导致的数据库页分裂问题——想拿 UUID 当 MySQL/PostgreSQL 主键，优先考虑 v7 而不是 v4。

常见疑问：真的不会重复吗

要真正安全，关键是随机源必须是加密级的（CSPRNG）。本工具调用浏览器原生的 crypto.randomUUID() / crypto.getRandomValues() 接口取随机数，而非 Math.random()，从源头保证生成质量。

相关阅读：随机数生成器；时间戳转换；进制转换。