关于 UUID 生成器
需要「不冲突的编号」时就会用到它：新表的自增主键换成分布式可用标识、消息队列去重 ID、日志追踪号、上传文件的临时名、测试数据的占位标识。UUID 的 128 位空间大到可以忽略碰撞概率，因此不需要中心机构发号，离线也能生成，这正是它在多服务架构里取代自增 ID 的原因。 本工具调用浏览器原生的 crypto.randomUUID() 生成 RFC 4122 定义的 v4 随机 UUID，也按 RFC 9562 在本地生成可按时间排序的 v7。两者的差别只在一个点上：v4 的 122 位全部随机，因此插入位置随机；v7 把毫秒时间戳放在高位，同一时刻生成的 ID 彼此邻近。 关于主键选型：用 v4 做主键时，B 树索引的写入位置在整棵树上游走，页分裂频繁、缓存命中率下降，写入密集的表会出现吞吐衰减与存储碎片；v7 因为时间前缀有序，插入基本落在索引尾部，更接近自增 ID 的写入特征，同时保留了不可预测性。只有在纯随机标识（会话、令牌、文件名）场景下才应优先用 v4。 边界与限制：UUID 的随机性不等于不可猜测——v1 直接编码了 MAC 地址与时间戳，任何人都能反推生成机器与时刻，因此不要用 v1 做对外暴露的标识；而 v4 的强度取决于随机源，用数学库的伪随机函数生成就失去了密码学保证，必须走 Web Crypto。存储上，36 字符文本形式占用很大，一千万行约 360 兆，改成 16 字节二进制列可压到约 160 兆并加快比较，代价是查询与日志里的可读性下降；常见折中是内部存二进制、对外展示带连字符的字符串。此外 UUID 是大小写不敏感的十六进制，做等值比较前建议统一转小写。 数据与隐私：生成的 UUID 常用于会话标识、追踪号与临时资源名，本身不是秘密，但如果同时把「ID 与用户身份的对应关系」展示在页面上就会带来风险。本工具完全在浏览器内调用系统随机源与时间，不请求服务器，也不记录任何生成结果。
批量生成与替代方案的取舍也值得提前想清楚。一次生成大量标识时，浏览器端与命令行端的成本差异主要在该用哪一端：需要几十万个用于灌测试数据时，命令行工具更合适；只在页面上取几个做样例时，浏览器端足够。UUID 之外还有几个常见替代：ULID 用 26 个字符的 Crockford 编码表示 128 位，同样按时间有序且更短，适合对存储与可读性都敏感的场景；Snowflake 类方案靠机器位与序列号保证有序，但需要维护机器编号；而数据库自增 ID 在单库单表下最简单，只有在分库分表或离线生成时才必须换成前几种。选型时把「是否有序」「是否可离线生成」「长度与存储成本」三项列出来逐条打勾，比凭印象选择更可靠。
实践中的分工建议也很简单：内部存储用 16 字节二进制并建立唯一索引，对外接口与日志统一输出带连字符的小写字符串，展示层不做任何截断；这样既拿到了存储与索引上的收益，也不牺牲排查时的可读性。
实现原理
v4 把 128 位中的 122 位填成随机值，剩下 6 位用于标记版本（第 13 个十六进制位固定为 4）与变体（紧随其后的一位取自固定集合）。v7 则相反：高 48 位放毫秒时间戳，其余为随机，因此同毫秒内生成的标识彼此相邻，插入索引时基本落在尾部而非随机位置。
生成任一 v4 UUIDf47ac10b-58cc-4372-a567-0e02b2c3d479（第 13 位恒为 4；第 17 位恒为 8/9/a/b）使用方法
- 打开 UUID 生成器页面
- 选择需要生成的 UUID 数量（1-1000 个）
- 点击「生成」按钮或选择大写/小写、是否带连字符等选项
- 点击 UUID 旁边的复制按钮或「复制全部」一键复制所有结果
使用场景
- 数据库主键 — 替代自增 ID，适合分布式系统避免主键冲突，支持离线生成、合并写入。
- API 请求 ID — 为每个 HTTP 请求打上唯一标记，便于日志追踪和分布式链路关联。
- 前端临时 key — Vue/React 列表渲染时为没有稳定 ID 的临时项分配 key，避免重渲染问题。
- 文件命名 — 批量上传或缓存时避免重名覆盖，文件名带 UUID 几乎不会冲突。
- 会话 token — 配合签名生成不可猜测的 session ID 或一次性令牌。
常见问题
UUID v4 会不会重复？
理论上会，但概率极低。UUID v4 由 122 位随机数构成，生成 100 亿个 UUID 出现一次碰撞的概率约为 50%——在工程上可视为永不冲突。
UUID 和 GUID 是同一个东西吗？
是。GUID 是微软对 UUID 的别名，二者格式完全一致，可互换使用。
为什么我的 UUID 总是以 4 开头？
第 13 位字符标识 UUID 版本，v4 固定为 4。如果需要可按时间排序的 UUID，可考虑使用本站的「ULID 生成器」。
UUID 安全吗？可以用作密钥吗？
v4 本身不是为加密设计的，但 122 位熵值已远超普通 token。如果需要更高安全等级，推荐使用本站的「令牌生成器」。
为什么不上传到服务端就能生成？
浏览器原生提供 crypto.getRandomValues() API，这是经过密码学评审的安全随机源，质量与服务端 /dev/urandom 等价。
UUID v4 和 v7 该怎么选？
纯随机、不希望泄露生成时间或对库兼容性有顾虑时选 v4；需要按时间排序、想让新记录自然排在索引末尾以减少随机主键的页分裂时选 v7。v7 前 48 位是毫秒时间戳，可以反推出生成时间，v4 则没有这个信息。作为数据库主键的高并发写入场景，v7 近似顺序写能提升 InnoDB 等 B+Tree 索引的局部性，所以多数新项目更倾向 v7；两者的标准显示格式保持一致。
去掉连字符的 UUID 还合法吗？
合法。UUID 本质是 128 位十六进制数据，连字符只是约定俗成的排版格式。去掉后是 32 个十六进制字符，仍是同一个 ID，很多数据库用 BINARY(16) 这类紧凑形式存储。只要生成和存储两端格式一致就没有问题；如果某 API 或库要求标准格式，再按 8-4-4-4-12 补回连字符即可。切勿在某一层手动去除、又在另一层原样拼接，避免被当成不同的值处理。
UUIDv4 会重复吗？概率有多大？
理论上有重复可能（122 位随机），但概率极低：生成 10 亿个 UUID 后出现一次碰撞的概率约十亿分之一。数据库仍建议加唯一约束兜底——不是因为它会撞，而是因为约束的成本远低于「万一」。