UUID生成器

UUID 生成器做的事很直接：点一下就生成一个符合 RFC 4122 v4 规范的随机 UUID（在 Windows、.NET 生态里也叫 GUID），需要多个时可以一次批量生成一整批。日常开发里，给数据库记录、消息、上传文件安排一个全局唯一的标识符是高频需求，手写或者临时找脚本都嫌麻烦，这个在线 UUID 生成工具就是把这一步压缩成一次点击。整个生成过程在浏览器本地完成、不上传，复制粘贴就能用。

v4 UUID 的本质是一个 128 位的值，用十六进制写成 8-4-4-12 共 32 个字符、加上连字符一共 36 位的形式。它并不依赖时间或机器信息，而是几乎全部由随机数填充：128 位里有 4 位固定为版本号（第 13 位十六进制字符恒为 4）、2 位固定为 variant 变体标志，剩下 122 位是随机的。规范的实现会用操作系统提供的密码学安全随机源（浏览器里是 crypto.getRandomValues）来取这 122 位，所以两次生成撞车的概率低到可以忽略——粗略地说，要出现一次碰撞，需要生成的数量达到 2 的 61 次方量级。

最常见的用法是当主键或唯一标识。比如在分库分表、多个服务各自写库的分布式场景里，自增 ID 需要中心协调，而各节点直接本地生成 UUID 就能保证不冲突，写入前不用回数据库查询。再比如做接口幂等：客户端为每次下单请求生成一个 UUID 作为幂等键（Idempotency-Key）随请求带上，服务端拿它去重，网络重试时就不会重复下单。此外像给上传文件命名避免重名、给一次调用链生成 trace id、批量造测试数据里的唯一字段，都可以直接把生成结果粘过去。

有两点容易踩坑。一是 v4 是纯随机、无序的，直接拿它当 MySQL InnoDB 的聚簇索引主键，会因为插入位置随机而带来页分裂和索引碎片、拖累写入性能；对顺序敏感的场景可以考虑按时间排序的 UUIDv7，或把 UUID 以 BINARY(16) 存储而非 CHAR(36) 来省空间。二是格式细节：RFC 建议输出用小写十六进制，但解析时大小写不敏感，标准形态带 4 个连字符、共 36 字符，有些系统会去掉连字符或外加花括号（如 .NET 的 GUID），存取时注意统一。还要记住 UUID 只保证唯一，并不保证不可预测，别把它当密码或安全令牌来用。

UUID生成器是一个免费的在线工具，打开网页就能用，不用下载也不用注册。平时大家搜的“uuid生成”、“guid生成”、“uuid在线生成”，说的都是这个。