UUID 生成器
生成UUID v4唯一标识符。浏览器本地处理，数据不上传服务器。
UUID 生成器
UUID（Universally Unique Identifier，通用唯一标识符）是一个 36 位的全局唯一字符串，本工具基于浏览器内置的 crypto.randomUUID() 生成 UUID v4，批量、本地、即时完成，数据不上传服务器。它广泛用于数据库主键、接口会话 ID、分布式系统节点 ID 等任何"绝不重复"的场景。
什么是 UUID？为什么用 v4？
UUID 形如 550e8400-e29b-41d4-a716-446655440000，由版本号、变体和随机数构成。UUID v4 采用纯随机数生成，理论上碰撞概率极低，几乎不可能撞车，因此不需要集中分配、不依赖中心数据库，即可保证跨系统、跨机器的唯一性。
在实际开发中，用 UUID 作主键可以避免自增 ID 暴露业务量、适合分布式数据库合并、也方便数据在多个系统间迁移或同步。
具体怎么用？
1. 选择要生成的个数（支持批量 1/3/5/10），点击"生成 UUID"。
2. 结果区会列出一个个完整的 UUID 字符串，可一键"复制全部"或逐条复制。
3. 复制后用于你的代码、配置或数据库即可。
UUID 和自增 ID 该怎么选？
自增 ID（1、2、3…）简单、紧凑、排序友好，但会暴露业务量，且在多机合并时容易冲突；UUID 则天然唯一、无需中心协调，适合分布式系统和数据迁移。一般规律：单机应用、对体积敏感的场景可用自增 ID；需要跨系统同步、分布式写入、或不愿暴露数据规模时，用 UUID 更稳妥。
结果怎么用？
生成的 UUID 可直接作为数据库主键、日志追踪 ID、订单号、API 幂等键等；也可以拼到文件名、临时令牌、缓存 key 中避免碰撞。若需要更短或可排序的标识，可结合时间戳或雪花算法（Snowflake）做进一步处理。
UUID 是什么：为什么分布式系统离不开全局唯一标识
UUID 全称是 Universally Unique Identifier（通用唯一标识符），也常被称为 GUID。它本质上是一串 128 位的数字，按约定格式写成由连字符分隔的 36 个字符。它解决的问题非常具体：在一个由很多台机器、很多个服务、甚至很多个数据中心组成的系统里，如何让每一条记录、每一个请求、每一个会话都拿到一个"全世界都不会重复"的名字，而且不依赖一个中央分配器去发号。这正是它和数据库自增主键最根本的区别——自增主键需要一个中心来记"下一个号码是多少"，而 UUID 让任何一台机器都能独立造出不会撞车的标识。正因如此，UUID 成了分布式数据库、消息队列、微服务追踪、会话管理和数据迁移场景里的标配。
我们日常接触的大部分"随机码""订单号后缀""trace id"背后，其实都是 UUID 在起作用。它不携带业务含义，只负责"唯一"，这种纯粹反而让它在跨系统拼装数据时非常省心：你不用担心两个系统各自从 1 开始编号而撞在一起。
UUID 的五个官方版本：怎么来的、用在哪
RFC 4122 定义了 UUID 的多个版本，区别在于"这一串 128 位到底是怎么算出来的"。下面这张表把五种版本放在一起，并标注了它们在真实项目里的常用程度：
| 版本 | 生成依据 | 典型用途 | 常用程度 |
|---|---|---|---|
| v1 | 基于时间戳（100 纳秒精度）加上生成节点的 MAC 地址 | 需要按时间粗略排序、且能回溯出生成机器的场景 | 较少（有隐私顾虑） |
| v2 | DCE 安全版本，在 v1 基础上嵌入 POSIX 的 UID/GID | 分布式安全系统里的身份标识，现实中极少见到 | 极少 |
| v3 | 基于命名空间 + 名称做 MD5 哈希（相同输入必得相同输出） | 需要由固定名称稳定派生出 ID，比如把 URL 映射成 ID | 较少 |
| v4 | 122 位全部来自随机数（版本位与变体位除外） | 绝大多数通用场景：数据库主键、会话 ID、令牌、日志追踪 | 最常用 |
| v5 | 基于命名空间 + 名称做 SHA-1 哈希，确定性派生 | 与 v3 同类但需要更强哈希、可复现的名称派生 | 常用（仅次于 v4） |
怎么用：对绝大多数 Web 项目和普通业务系统来说，直接选 v4 就对了——它最简单、最通用，而且不需要任何输入。只有当你"希望同一个名字每次都生成同一个 ID"（比如按 URL 生成稳定标识）时，才需要 v3 或 v5 这种基于名称的确定性版本。v1 因为会把 MAC 地址写进 ID，现在很少在新项目里使用。
8-4-4-4-12：UUID 的书写格式与每一位含义
一个标准 UUID 长成 36 个字符，分布在五段里，段长分别是 8、4、4、4、12，中间用连字符隔开，所以叫 8-4-4-4-12 格式。去掉连字符后是 32 个十六进制字符，也就是 128 位二进制。这 128 位里有两个特殊位置被"征用"来标注身份：
第一，第 3 段的第一个十六进制字符（首字节的高 4 位）固定表示版本号。比如 v4 的 UUID，这一段一定以数字 4 开头；v1 以 1 开头；v5 以 5 开头。第二，第 4 段的第一个十六进制字符（首字节的高 2 位）固定表示变体（variant），按照 RFC 4122 它必须是二进制 10，落到十六进制上就是这一位的取值只能是 8、9、A 或 B 之一。只要看到第 4 段开头是这四个字符之一，就可以判断它是符合 RFC 4122 的 UUID。
真实算例：拆解一个 UUID 字符串
算例 1（按简报示例拆解）：取字符串 123e4567-e89b-12d3-a456-426614174000。先按 8-4-4-4-12 切分：第 1 段 123e4567（8 位）、第 2 段 e89b（4 位）、第 3 段 12d3（4 位）、第 4 段 a456（4 位）、第 5 段 426614174000（12 位）。看第 4 段首字节 a，十六进制 a 等于二进制 1010，其高 2 位为 10，符合 RFC 4122 变体位。再看第 3 段首字节 1，表示它属于版本 1 的形态。若要将其改造成标准的 v4，只需把第 3 段首字节改成 4，得到 123e4567-e89b-42d3-a456-426614174000——此时第 3 段以 4 开头、第 4 段仍以 a 开头，便是一个格式正确的 v4。本工具生成的每一次结果，第 3 段都固定以 4 开头、第 4 段固定以 8/9/A/B 开头，可以随手挑一条按上面的方法自行校验。
常见问题：关于 UUID 你必须知道的几件事
UUID v4 真的不会重复吗？碰撞概率有多大？
v4 有 122 位是随机的，随机空间高达 2 的 122 次方，大约是 5.3 × 10 的 36 次方。要理解这个量级：即使你每秒生成 10 亿个 UUID，连续生成 100 年，发生一次碰撞的概率仍然远低于被陨石砸中的概率。所以它不是"数学上绝对不可能重复"，而是"在可预见的实践尺度里可以放心当作唯一"。真正需要小心的不是随机碰撞，而是你自己的代码把同一个 UUID 重复写入了两遍，那种"重复"和算法无关。
UUID v1 会泄露 MAC 地址，这有什么隐私风险？
v1 把生成机器的 MAC 地址直接编进了 UUID 的第 5 段。也就是说，任何人拿到一个 v1 UUID，理论上能反推出"它是在哪台网卡上生成的"，进而关联到具体的设备甚至物理位置。在当年内网环境里这不算大问题，但在今天的公网、多租户云环境里，把硬件地址写进对外暴露的 ID 显然不合适。这也是为什么新项目普遍改用不携带任何硬件信息的 v4，而 v1 只在一些需要按时间排序且信任网络边界的内部系统里保留。
UUID v4 和 v5 该怎么选？
核心差别是"随机"还是"确定性"。v4 每次都不同，适合当你只关心唯一、不关心它和某个名字的关系时，比如会话 ID、令牌、日志追踪号。v5（以及 v3）则相反：给定同样的命名空间和同样的名称，永远得到同一个 UUID，适合"我想把一个稳定存在的东西（如一个 URL、一个用户名）映射成一个固定 ID"的场景，比如把文章链接映射成内部的稳定标识。简单记：要唯一且彼此无关，用 v4；要"同名必同值"，用 v5。
UUID 和数据库自增 ID 到底有什么区别？
自增 ID（1、2、3……）由数据库统一发号，紧凑、有序、索引友好，但有两个硬伤：一是它会把"你一天新增了多少条"这种业务规模直接写在 ID 里，竞争对手拿到订单号就能估出你的销量；二是当数据要在多台机器、多个库之间合并或迁移时，两个库都从 1 开始，必然冲突。UUID 用更长的字符串换来了"任何机器独立生成也不冲突"和"不暴露业务量"两个好处，代价是体积更大（36 字符 vs 整数）、无序导致索引插入略慢。实际选型时：单机、对存储和顺序敏感，用自增；分布式写入、跨系统迁移、不想暴露规模，用 UUID。