🆔 UUID 生成器

关于 UUID 生成器

UUID（Universally Unique Identifier，通用唯一标识符）是一个 128 位（16 字节）的标识符标准，格式为 32 个十六进制数字分成 5 组，中间用连字符连接。标准格式如：550e8400-e29b-41d4-a716-446655440000。

UUID 有多个版本，本工具生成的是最常用的 UUID v4（随机版本）。v4 的 128 位中除了 4 位用于标识版本号、2 位用于标识变体，其余 122 位均由高质量随机数生成器产生。理论上，每秒生成 10 亿个 UUID，需要 100 亿年才可能产生一次重复，在实际应用中几乎可以忽略重复概率。

使用说明

1. 设置数量 — 通过输入框选择需要生成的 UUID 数量（1-100 个）
2. 生成 — 点击「生成 UUID」按钮，工具立即生成指定数量的 UUID v4
3. 复制 — 点击「复制全部」一键将结果复制到剪贴板，方便粘贴到代码或文档中

常见应用场景

• 数据库主键 — 使用 UUID 作为主键可以避免自增 ID 的主键冲突问题，特别适合分布式数据库和多主复制架构
• 用户标识 — 在分布式系统中为用户、订单、会话等实体生成全局唯一的标识符
• API Key / Token — 生成唯一的 API 访问密钥或会话令牌
• 文件命名 — 为上传的文件生成唯一文件名，避免同名文件覆盖

常见问题

Q: UUID v4 和 v1 有什么区别？

UUID v1 基于时间戳和 MAC 地址生成，可以追踪生成时间和设备，但存在隐私风险。UUID v4 完全基于随机数，不包含任何时间或设备信息，隐私性更好。

Q: UUID 作为数据库主键有性能问题吗？

UUID 是 128 位的散列值，作为主键时 B+ 树的插入可能不是顺序的，导致页分裂。对于小规模应用影响不大，大规模高并发场景建议考虑有序的雪花算法 ID。

UUID 格式解读

UUID 是 128 位标识符，通常写成 8-4-4-4-12 的 36 字符形式，例如 550e8400-e29b-41d4-a716-446655440000。其中每个字符都是十六进制数字，连字符只用于分组显示。第四组的首位表示版本号，例如 4 代表 UUID v4，7 代表 UUID v7。理解格式后，就能通过字符串快速判断 UUID 版本。

UUID v4 的生成原理

本工具使用浏览器内置的 crypto.randomUUID() 生成 UUID v4。v4 的 128 位中包含版本位和变体位，其余位由加密级随机源生成。相比使用普通随机数拼字符串，这种生成方式更安全，也更适合作为数据库主键、请求追踪 ID 和临时令牌。随机性保证了同一时间在不同设备上生成重复值的概率极低。

选 UUID 还是自增 ID

自增 ID 连续、存储小、查询友好，但只在单个数据库范围内保证唯一，且容易被枚举。UUID 适合分布式系统、多库合并、客户端离线生成和对外暴露 ID 的场景。单机小项目若没有合并与安全需求，使用自增 ID 更简单；需要全局唯一时应优先 UUID，大规模高并发可进一步考虑 v7 或雪花 ID。

典型使用场景

• 为数据库主键生成不依赖数据库自增的唯一标识
• 为订单、会话、文件、埋点事件分配独立 ID
• 在日志链路中作为 requestId，把前端错误、接口日志和数据库记录串联起来
• 作为公开页面或接口中的资源 ID，降低被顺序枚举的风险

批量生成后的使用建议

生成后可以先复制全部结果，再按业务需要逐条使用。作为主键时建议统一大小写，并避免在字符串中混入换行或空格。数据库存储 UUID 时，应优先选择原生 UUID 类型或 BINARY(16)，而不是直接使用 VARCHAR(36)，前者占用更少、索引更高效。生成数量较大时，可以先在文本工具中查看总字符数，估算接口或文件大小。

安全与权限提醒

UUID 的高随机性只能提高枚举难度，不能替代权限校验。即使资源 ID 无法被猜测，后端仍必须验证当前用户是否有权访问。不要把 UUID 当作密钥，不要把 v1 UUID 暴露给外部用户；v1 包含时间与设备相关信息，存在隐私风险。若生成的是敏感令牌，还应结合过期时间、吊销机制和访问日志一起设计。

requestId、幂等键与资源 ID 的差别

UUID v4 可以作为请求追踪 ID，但要区分三种标识：requestId 用于串联一次请求日志；幂等键用于防止重复下单或重复扣款；资源 ID 用于长期标识数据库实体。三者都要求全局唯一，但幂等键通常还需要租户、接口和业务窗口等约束，不能只靠一个随机 UUID 代替业务去重。

标识	推荐形式	生命周期	重要提醒
请求追踪	req_ + v4	一次请求或短期链路	前后端、网关和日志统一字段名
幂等键	业务规则 + 随机值	按订单或支付窗口	服务端必须持久化并做原子校验
资源 ID	v4、v7 或原生 UUID 类型	实体全生命周期	权限校验不能依赖“猜不到 ID”
公开分享链接	随机 token + 过期时间	短时有效	UUID 不是密钥，最好与签名和限流配合

为方便日志检索，可以统一使用小写带连字符格式，并在数据库中使用原生 UUID 或 16 字节二进制存储。紧凑 32 字符无连字符格式传输更短，但混用会增加解析、索引和排障成本，整条链路必须保持一致。

版本与选择速查

• v4 — 随机生成，无时间与设备信息，隐私好，适合大多数应用
• v7 — 时间有序，兼顾随机性与索引性能，适合大规模数据主键
• v1 — 包含时间与 MAC 地址，可能泄露设备信息，一般不建议对外使用
• v3/v5 — 基于名称稳定生成，适合需要确定性映射的场景
• 雪花 ID — 时间有序的 64 位 ID，适合高并发内部系统，但依赖机器 ID 协调

使用建议

生成 UUID 后先确定使用方式：数据库主键要统一字段类型，日志追踪要统一大小写，接口参数要验证长度与格式。批量生成时每次结果相互独立，可以直接使用；如果希望每次生成数量不同，可在输入框中调整数量再点击生成。不要把生成结果当作加密令牌单独保护敏感操作，权限校验仍然必不可少。

一条完整的 ID 设计思路

先回答三个问题：数据是否需要跨库合并？ID 是否会暴露给用户？写入量是否很大？如果都需要全局唯一且对外使用，优先 UUID v4 或 v7；如果只是单库内部主键，自增 ID 更省空间；如果追求高并发下的顺序插入，可在 UUID v7 与雪花 ID 之间做性能测试。

确定方案后统一写入规范：数据库字段类型、大小写格式、是否带连字符、日志展示格式都要一致。批量生成只是其中一环，后续的索引、迁移和权限校验同样重要。

使用本工具时建议一次生成完成后立即复制并保存到目标环境，避免多次刷新页面造成结果混淆。生成的 UUID 可以用于本地测试、接口联调和数据库填充，不需要登录或安装任何软件。

无论选择哪种 ID 方案，都应该先做小规模验证再迁移线上数据。UUID 不是万能答案，但当你需要跨系统、跨环境保持标识唯一时，它是最简单可靠的起点。

总之，先把唯一性、可见性、写入量和迁移成本写进设计文档，再选择生成工具，会让后续开发更顺利。