UUID 生成器

格式选项

大写字母

包含连字符

生成数量

1 个

免费在线UUID/GUID/ULID/NanoID生成器，支持5种唯一ID格式、批量最多100条、格式自定义和UUID验证识别，打开即用适合数据库主键和测试造数。

什么是 UUID？

UUID（Universally Unique Identifier，通用唯一识别码）是一种128位的标识符标准，由开放软件基金会（OSF）标准化，定义在 RFC 4122 中。它的目的是让分布式系统中的所有元素都能有唯一的标识信息，而不需要通过中央控制端来做ID的指定。

一个标准的UUID形如 `550e8400-e29b-41d4-a716-446655440000`，由32个十六进制数字组成，以连字符分成5段（8-4-4-4-12）。理论上UUID v4的碰撞概率约为1/10^36，即每秒生成10亿个UUID，持续约800年才会有50%概率发生一次碰撞，实际应用中可以认为是唯一的。

UUID被广泛应用于数据库主键、分布式追踪ID、请求Request-ID、日志Trace-ID、文件唯一命名、测试数据ID、会话标识等场景，几乎所有主流编程语言都内置了UUID生成库。

适用场景

数据库设计时生成 UUID v4 作为表记录主键，避免自增ID泄露数据量
分布式系统或微服务架构中使用 ULID 作为可排序的全局唯一请求追踪ID
接口开发与联调时批量生成一批 UUID 作为测试数据和模拟订单号/用户ID
前端URL短链或分享链接中使用 NanoID 替代UUID，更短更美观无需URL编码
使用 UUID v5 基于固定命名空间生成确定性ID，确保相同输入始终得到相同输出
调试日志或第三方文档中遇到不确定格式的ID时，使用验证功能识别ID类型和版本

使用方法

在上方卡片中选择需要生成的ID类型：UUID v4（推荐）、v1、v5、ULID或NanoID
如选择UUID v5，需输入命名用的字符串；其他ID可直接设置格式选项
根据需要切换大小写和连字符开关，通过快捷按钮或滑块设置批量生成数量（1-100）
点击生成按钮后查看结果列表，可逐条复制、一键复制全部或导出TXT/JSON文件
如需验证已有ID，切换到「验证」标签粘贴ID字符串即可得到类型和版本信息

功能特点

五种ID一页覆盖：同时支持 UUID v1（时间戳）、v4（随机）、v5（命名空间）、ULID（可排序）、NanoID（URL安全），一个工具满足不同技术栈需求
UUID验证识别：切换到验证标签，粘贴任意ID即可识别是UUID哪个版本，还是ULID/NanoID格式，调试时快速排查问题
批量生成最高100条：支持1-100条任意数量批量生成，测试造数不再手动一条一条复制
格式灵活切换：UUID支持大小写和连字符开关，适配数据库、URL、配置文件等不同场景的格式要求
导出与历史记录：支持一键复制全部、导出TXT/JSON文件，生成历史本地保存可随时恢复，批量操作更高效
纯前端安全随机：使用浏览器crypto API生成加密级随机数，ID不上传服务器，断网可用

代码示例

JavaScript 生成 UUID v4

javascript

现代浏览器和 Node.js 14.17+ 内置了 Web Crypto API，可以直接生成UUID v4，无需第三方库。

// 现代浏览器 / Node.js 19+
const id = crypto.randomUUID();
console.log(id); // "550e8400-e29b-41d4-a716-446655440000"

// Node.js 14.17 - 18.x
const crypto = require('crypto');
const id = crypto.randomUUID();

Python 批量生成 UUID

python

使用 Python 标准库 uuid 模块批量生成多个 UUID v4，适合测试数据准备。

import uuid

# 生成单个UUID
uid = uuid.uuid4()
print(uid)

# 批量生成10个
for _ in range(10):
    print(uuid.uuid4())

# 生成无连字符的大写UUID
print(uuid.uuid4().hex.upper())

Shell 命令行生成 UUID

bash

在 Linux/macOS 终端中快速生成UUID，适合shell脚本中使用。

# Linux
uuidgen

# macOS
uuidgen | tr 'A-Z' 'a-z'

# 直接从系统随机文件读取（最原始方式）
cat /proc/sys/kernel/random/uuid

唯一 ID 该选哪种方案？

UUID 不是唯一选择，数据库自增 ID 和 Snowflake 也是主流主键方案。先看「数据规模、是否需要全局唯一、是否需要按时间排序」再选具体方案，能少走很多弯路。

UUID v1 / v4 / v5 / ULID / NanoID：该选哪个？

5 种 ID 在数据规模、排序性、字符长度上各有取舍。先看「用在哪里 + 是否需要排序 + URL 是否直接用」做决策，比按数字本身更靠谱。

方案	推荐场景	排序性	长度	推荐度
`UUID v1`	需要按时间排序、能接受泄露 MAC 地址和生成时间的内部系统	按时间有序	36 字符	⚠️ 一般不推荐（泄露隐私）
`UUID v4`	数据库主键、通用标识、绝大多数业务场景	无序（随机）	36 字符	✅ 通用首选
`UUID v5`	需要确定性输出（相同输入 → 相同 UUID）的场景	无序	36 字符	✅ 命名空间固定时推荐
`ULID`	分布式系统主键、日志追踪、需要按时间排序的索引	按时间有序（前 48 bit 是毫秒时间戳）	26 字符	✅ 分布式系统首选
`NanoID`	URL 短链、Cookie 标识、前端 JS 引用	无序（随机）	21 字符（默认）	✅ 短 ID 场景首选

UUID vs 数据库自增 ID vs Snowflake ID：主键方案怎么选？

这三种是后端主键最常见的方案，决定了系统的扩展能力、并发安全和性能特征。按「数据规模 / 是否有全局唯一要求 / 是否需要可读」决策能避免后期架构调整。

维度	UUID	数据库自增 ID	Snowflake
`全局唯一`	✅ 是（理论上）	❌ 否（分库分表会重复）	✅ 是（数据中心+机器 ID 保证）
`数据量泄露`	✅ 不泄露	❌ 直接泄露（递增 1, 2, 3 暴露真实数据量）	⚠️ 时间位泄露生成时间（不直接泄露总量）
`排序性`	❌ 无序（ULID 例外）	✅ 单调递增（B-Tree 友好）	✅ 趋势递增（同一毫秒内有序）
`分库分表`	✅ 天然支持	❌ 需引入发号器或改造	✅ 通过 worker ID 区分
`存储成本`	⚠️ 高（BINARY(16) 16 字节）	✅ 低（BIGINT 8 字节）	✅ 低（BIGINT 8 字节）
`适合场景`	多服务/分布式主键、对外标识、数据量敏感业务	单体应用、后台管理系统、不需要全局唯一	高并发 IM、订单号、消息 ID（需自行实现）

最佳实践

生产数据库主键优先选 UUID v4 或 ULID，避免 v1

UUID v1 的后 48 bit 是 MAC 地址，前 48 bit 是 100ns 精度时间戳——**这两个字段可被还原成机器指纹和生成时间**。v1 在 RFC 4122 中已明确「only when backward compatibility is needed」（仅在需要向后兼容时使用）。生产环境应优先选 v4（随机）或 ULID（可排序），v1 仅在做调试、需要追溯生成机器时偶尔使用。**绝对不要**用 v1 作为对外暴露的用户 ID、设备 ID 或订单号。

UUID v1、v4、v5 应该怎么选？

UUID 长度 128 bit ≠ 熵值：v4 实际只有 122 bit

UUID v4 虽然有 128 bit 总长，但**前 4 bit 是版本号（固定为 0100），后 2 bit 是变体号（固定为 10）**，真正随机的只有 122 bit。这是 RFC 4122 规定的格式约束，**任何声称「128 bit 全随机」的 UUID v4 库都是错误实现**。另外 v4 的后 64 bit 中第 7 个字节的高 2 bit 也是变体字段，实际熵更低。设计系统时按 122 bit 算安全性（而非 128 bit），避免低估碰撞风险。

RFC 4122 - UUID 规范

存储 UUID 务必用 BINARY(16) 列而不是 VARCHAR(36)

UUID v4 字符串 `550e8400-e29b-41d4-a716-446655440000` 看起来紧凑，实际 VARCHAR(36) 存 36 字节+ 2 字节长度 = 38 字节，**比 BINARY(16) 多 2.4 倍存储空间**。MySQL/PostgreSQL/MSSQL 都内置 UUID 函数支持直接写 BINARY(16)，索引大小也减半。表超过 1 亿行时 VARCHAR(36) 主键索引会让 B-Tree 高度多 1-2 层，**查询性能下降 30-50%**。前端展示时再转字符串，业务层一律 BINARY(16) 传输。

UUID / ULID / NanoID 对比表

URL 场景用 NanoID 或无连字符 UUID，避开 URL 编码

UUID v4 字符集是 `[0-9a-f-]`，**连字符 - 在 URL path 中需要两次 URL 编码**（先转义为 %2D，再转义为 %252D），非常难看。两种解决方案：**（1）URL 场景直接用 NanoID**（默认 21 字符 URL 安全）；**（2）UUID v4 + 关闭连字符**输出 32 位纯 hex，作为 URL path segment 无需编码。Cookie 场景同样优先 NanoID（A-Za-z0-9_-）或无连字符 UUID，避开 `+` `/` `=` 字符（Base64 字符集）。

生成的 UUID 可以去掉连字符或转大写吗？

批量生成后务必去重，生成器 bug 可能造成重复

UUID v4 碰撞概率约 1/10^36，理论上无需去重——**但工程上不要相信理论**。Linux 内核 RNG 故障、Node.js 早期版本的 `crypto.randomUUID` 实现 bug、Cloud VM 启动时熵源不足等真实事故都导致过批量生成的 UUID 包含重复值。**生产环境中批量生成 10w+ UUID 后必须用 `SELECT id, COUNT(*) FROM t GROUP BY id HAVING COUNT(*) > 1` 做一次去重校验**，发现问题立即回滚生成器版本。这是数据迁移、批量导入场景下用血的教训换来的最佳实践。

可以一次性批量生成多条 UUID 吗？

常见问题

UUID 和 GUID 有什么区别？

UUID（Universally Unique Identifier）和 GUID（Globally Unique Identifier）本质上是同一个东西，只是叫法不同：UUID 是 IETF 标准（RFC 4122）的正式名称，GUID 是微软在 Windows 生态中的习惯叫法。两者的格式完全一致，都是形如 `550e8400-e29b-41d4-a716-446655440000` 的128位标识符。本工具生成的标准 UUID 可以直接用于任何需要 GUID 的场景。

UUID v1、v4、v5 应该怎么选？

UUID v1 基于时间戳和MAC地址生成，按时间有序可追溯，但可能泄露MAC地址；UUID v4 完全基于随机数生成，是最常用、最安全的选择，适合绝大多数主键和标识场景；UUID v5 是基于命名空间的哈希版本（SHA-1），相同命名空间+相同名称始终生成相同UUID，适合需要确定性输出的场景。一般开发中默认选 UUID v4 即可。

ULID 和 NanoID 相比 UUID v4 有什么优势？

ULID（26字符）比 UUID（36字符含连字符）更短，按时间排序，适合数据库索引和日志追踪；NanoID（21字符默认）更短更快，用URL安全字符，URL和Cookie中无需转义，体积比UUID小30%。三者碰撞概率都极低，但分布式系统中ULID的可排序性更有优势，NanoID在前端/URL场景下更友好。

可以一次性批量生成多条 UUID 吗？

可以。本工具支持1到100条批量生成，点击数量按钮或拖动滑块设定数量后一键生成，适合测试造数、批量导入和脚本准备唯一ID。生成后支持一键复制全部结果，也可导出为TXT文本或JSON文件。

批量生成操作说明

可以验证一个字符串是不是合法的 UUID 吗？

可以。切换到「验证」标签页，输入任意字符串，工具会自动识别并验证：标准UUID（v1/v3/v4/v5）会告知具体版本号，还支持识别ULID（26位Crockford Base32格式）和NanoID（21位URL安全字符）格式，开发调试中快速排查ID格式问题非常方便。

在线生成 UUID 会泄露到服务器吗？安全吗？

完全安全。本工具所有ID生成和验证都在你本地浏览器中通过JavaScript完成，使用crypto.getRandomValues()加密安全随机数，不会向任何服务器发送你生成的ID，也不会记录生成历史到云端。即使断网也可以正常使用，适合在企业内网和敏感项目中使用。

生成的 UUID 可以去掉连字符或转大写吗？

可以。对于UUID v1/v4/v5，工具提供两个开关：「大写」可切换输出大小写，「连字符」可去掉中间的横杠（适合在URL、配置文件或某些数据库中使用无连字符格式）。ULID和NanoID默认无连字符，也支持大小写切换。

为什么推荐用在线工具而不是命令行生成UUID？

命令行（如Linux的uuidgen、Python的uuid模块）需要开发环境支持，在线工具打开即用，无需安装任何软件。此外本工具还集成了UUID版本识别、批量导出、历史记录等增值功能，在跨设备（如帮非技术同事生成ID）或临时需要时更方便。

术语表

UUID: 通用唯一识别码（Universally Unique Identifier），128位长度，RFC 4122标准，常用版本有v1（时间戳+MAC）、v4（随机）、v5（SHA-1哈希）。
GUID: 全局唯一标识符（Globally Unique Identifier），微软对UUID的称呼，两者格式和用途完全相同。
ULID: 按字典序可排序的唯一标识符（Universally Unique Lexicographically Sortable Identifier），26个字符，使用Crockford Base32编码，前48位为时间戳，可按创建时间排序。
NanoID: 一种轻量级的唯一ID生成方案，默认21个URL安全字符（A-Za-z0-9_-），比UUID更短、更快，适合前端和URL场景使用。
UUID v1: 基于时间戳和MAC地址的UUID版本，按时间可排序，但可能泄露MAC地址和生成时间，安全性低于v4。
UUID v4: 完全基于随机数生成的UUID版本，使用最广，碰撞概率极低，是开发中默认选择。
UUID v5: 基于SHA-1哈希的命名空间UUID版本，相同命名空间+相同名称输入会产生相同的UUID输出，适合确定性场景。
碰撞概率: 两个随机生成的ID恰好相同的概率。UUID v4的碰撞概率约为170亿分之一万亿，可以在实际工程中忽略。
Crockford Base32: Douglas Crockford设计的Base32编码，使用排除了I/L/O/U的大写字母和数字，避免易混淆字符，ULID使用此编码。

UUID / ULID / NanoID 对比表

特性	UUID v4	ULID	NanoID
长度	36字符（含连字符）/ 32字符（无连字符）	26字符	默认21字符
字符集	16进制（0-9a-f）	Crockford Base32（32个字符）	URL安全（64个字符）
排序性	无序（随机）	按时间有序	无序（随机）
URL安全	需转义（含连字符和字母数字）	基本安全（大写字母+数字）	完全URL安全
生成速度	快	快	比UUID快约60%
碰撞概率	1/10^36	1/10^36	1/10^34（21位时）
典型场景	数据库主键、通用ID	分布式系统、日志追踪	短链URL、前端标识、Cookie

各语言生成 UUID 的常用方法

语言	代码
JavaScript	`crypto.randomUUID() // 现代浏览器/Node.js 19+`
Python	`import uuid; uuid.uuid4()`
Java	`UUID.randomUUID()`
Go	`github.com/google/uuid; uuid.New()`
Bash/Linux	`uuidgen 或 cat /proc/sys/kernel/random/uuid`

UUID 生成器

格式选项

生成数量

相关推荐

密码生成器

JWT 解码、验证与生成

MD5 哈希值

十六进制转换器

SHA-256 哈希

什么是 UUID？

适用场景

使用方法

功能特点

代码示例

JavaScript 生成 UUID v4

Python 批量生成 UUID

Shell 命令行生成 UUID

唯一 ID 该选哪种方案？

UUID v1 / v4 / v5 / ULID / NanoID：该选哪个？

UUID vs 数据库自增 ID vs Snowflake ID：主键方案怎么选？

最佳实践

生产数据库主键优先选 UUID v4 或 ULID，避免 v1

UUID 长度 128 bit ≠ 熵值：v4 实际只有 122 bit

存储 UUID 务必用 BINARY(16) 列而不是 VARCHAR(36)

URL 场景用 NanoID 或无连字符 UUID，避开 URL 编码

批量生成后务必去重，生成器 bug 可能造成重复

常见问题

UUID 和 GUID 有什么区别？

UUID v1、v4、v5 应该怎么选？

ULID 和 NanoID 相比 UUID v4 有什么优势？

可以一次性批量生成多条 UUID 吗？

可以验证一个字符串是不是合法的 UUID 吗？

在线生成 UUID 会泄露到服务器吗？安全吗？

生成的 UUID 可以去掉连字符或转大写吗？

为什么推荐用在线工具而不是命令行生成UUID？

术语表

UUID / ULID / NanoID 对比表

各语言生成 UUID 的常用方法

Authoritative References