🆔 生成类型

个 可填 1 ~ 1000

⚙️ 输出格式

📖 当前类型说明

📤 生成结果

🔍 六种 ID 对比

类型长度示例特点
UUID v4 36 f47ac10b-58cc-4372-… 全随机,最通用;不能按时间排序
UUID v7 36 01932c8a-7f3b-7c4d-… 前 48 位时间戳,字典序即时间序,推荐
UUID v1 36 2c5ea4c0-4067-11e9-… 100ns 时间戳;传统实现会泄露 MAC
ULID 26 01J8ZK2M3N4P5Q6R7S8… Base32(无 I/L/O/U),时间有序、可读性好
NanoID 21 V1StGXR8_Z5jdHi6B-m… URL 安全,长度可调,短小好看
ObjectId 24 507f1f77bcf86cd7994… MongoDB 默认 _id,可从 ID 反推时间

⚠️ 使用提醒:
· 本工具优先使用 crypto.getRandomValues(密码学安全随机源)。只有在该 API 不可用的极老浏览器里才会降级到 Math.random(),此时右侧「随机源」一栏会明确标红提示——若用于生产环境,请确认显示的是「密码学安全」。
· 生成的 ID 只存在于你的浏览器里,本工具不存储、不上传、也无法再找回,请自行复制或导出保存。
· 网页端生成的 UUID 不能保证是 UUID v1 的严格标准实现:v1 最后 12 位本应是网卡 MAC,本工具改用随机值并置多播位,这样既保留了时间戳特性又不会泄露硬件信息——如果你需要与别的系统做 v1 互操作,请留意这一点。
· 「唯一性」是概率意义上的:UUID v4 需要生成约 2.7×10¹⁸ 个才有约 50% 概率出现一次碰撞,日常使用无需担心,但数据库层面仍建议加唯一索引做兜底。

🆔

UUID 生成器

效率工具 完全免费 🌙 支持黑夜模式 🔒 纯前端本地生成 🎲 密码学安全随机源

写 SQL 造测试数据要好几十个主键、给接口压测要一批不重复的 ID、做短链接要一批短码——手动编 ID 既不现实也容易重复。
这个工具一次给全六种主流唯一 ID,并且说明它们各自适合什么场景,免得选错:
· UUID v4:最通用、最省心,Java / Python / Go 默认生成的几乎都是它,但不能按时间排序;
· UUID v7:前 48 位是毫秒时间戳,因此字典序就是时间顺序。做数据库主键时索引局部性远好于 v4,是新建系统的推荐选择;
· UUID v1:100ns 时间戳精度最高,但传统实现会把网卡 MAC 写进 ID 里——本工具用随机节点替代,不会泄露你的硬件信息;
· ULID:26 个字符的 Base32,刻意去掉了容易看错的 I、L、O、U,时间有序、大小写不敏感,适合做对外可见的 ID;
· NanoID:默认 21 个字符,URL 安全、长度可调,短链接与分享码的常见选择;
· ObjectId:MongoDB 的默认 _id,24 位十六进制,还能从 ID 反推出创建时间。
另外提供「大写 / 去连字符 / 加引号 / 单行逗号分隔」四个格式开关,复制出去就能直接贴进代码、SQL 或 JSON。所有生成均在浏览器本地完成,不联网。

类别效率工具
运行方式纯前端 · 离线可用
单次上限1000 个

核心特性

UUID v4 / v7 / v1
ULID 时间有序
NanoID 长度可调
MongoDB ObjectId
批量最多 1000 个
密码学安全随机源
大写 / 去连字符 / 加引号
支持黑夜模式

该选哪一种?

做数据库主键,且在意写入性能 → 选 UUID v7 或 ULID。它们把时间戳放在前面,新记录会集中插在索引末尾,避免随机写入把 B+ 树索引打散。
只求省事、不关心排序 → 选 UUID v4。生态支持最广,几乎任何语言的任何库都认。
要给别人看、希望短一点好念 → 选 ULID(26 字符)或 NanoID(21 字符,可再调短)。
做短链接、分享码、文件名 → 选 NanoID,URL 安全且没有连字符,不用再做转义。
在用 MongoDB → 直接用 ObjectId,它就是 Mongo 的默认主键格式,还能反推创建时间。
需要极致的纳秒级时间精度 → 选 UUID v1,但要注意它的隐私问题与排序友好度都不如 v7。

怎么用

  1. 第 1 步
    选生成类型。不确定就先用默认的 UUID v4;要做主键建议选 UUID v7。
  2. 第 2 步
    填数量(1~1000),需要的话再调 NanoID 长度。
  3. 第 3 步
    按需勾选格式选项:大写、去连字符、加双引号、单行逗号分隔。
  4. 第 4 步
    点「🎲 生成」,确认右侧「随机源」显示的是「✅ 密码学安全」,然后复制或导出。

常见搭配

造 SQL 测试数据:勾上「每个值加双引号」+「单行输出」,复制出来直接塞进 IN (...) 或 VALUES 里。
写配置文件 / 常量数组:同样用「加双引号 + 单行」得到 "a-1", "a-2", "a-3" 这样可直接粘贴的列表。
拿去当密码用:正好顺手——UUID v4 有 122 位随机量,但注意它是小写十六进制,字符集只有 16 种,做密码不如专门的密码生成器。
压测造 ID:直接生成 1000 个导出成文件,作为压测数据源。

更新记录

  • v1.0 2026-09-11 工具上线:支持生成 UUID v4、UUID v7(同毫秒内单调递增)、UUID v1(随机节点,不泄露 MAC)、ULID(Crockford Base32)、NanoID(长度 4~64 可调)、MongoDB ObjectId(含自增计数器)共六种唯一 ID;单次最多生成 1000 个;提供大写、去连字符、加双引号、单行逗号分隔四个格式开关,并对非 UUID 类型自动禁用「去连字符」选项;优先使用 crypto.getRandomValues 密码学安全随机源并在界面明确标注当前使用的随机源;提供生成数量、单条长度、总长度统计与六种 ID 横向对比表;支持复制与导出 txt;适配黑夜模式;纯前端本地生成。

常见问题

UUID v4 和 v7 到底该用哪个?
核心差别只有一个:v7 的开头是时间戳,v4 的开头是随机数。
这个差别带来三个实际后果:
· 数据库写入性能:v4 主键是随机分布的,每条新记录都会插到 B+ 树的随机位置,导致页分裂与磁盘随机写;v7 主键随时间递增,新记录集中在索引末尾,接近顺序写。数据量越大差距越明显。
· 可读性:v7 一眼就能看出大致创建时间,排查问题时很有用;v4 完全看不出。
· 生态兼容性:v4 十几年了,所有语言、所有数据库、所有第三方服务都支持;v7 是 2024 年才正式定稿的 RFC 9562,部分老旧系统与数据库类型可能还不认。
结论:新项目、自己可控的技术栈 → 用 v7;要对接一堆老旧系统或第三方服务 → 用 v4 最稳妥。
这些 ID 真的不会重复吗?
是概率意义上不会重复,不是数学上保证不重复。
UUID v4 有 122 位随机量,需要生成约 2.7 × 10¹⁸ 个才有约 50% 的概率出现一次碰撞——即使每秒生成 10 亿个,也要跑 85 年才到这个量级。
NanoID 默认 21 字符(约 126 位随机量),碰撞概率与 v4 同量级;如果你把长度调到 4,就只有约 24 位随机量,几万个就会开始明显碰撞,所以调短时请自行评估数量级。
另外提醒:网页生成的随机数不会跨设备去重。如果你在多台机器上分别生成,理论上仍可能撞车(概率极低)。生产环境请务必在数据库层面加唯一索引做最后兜底——这是唯一可靠的保证方式。
右侧显示「✅ 密码学安全」是什么意思?为什么重要?
表示生成 ID 用的是浏览器的 crypto.getRandomValues(),它由操作系统提供的密码学安全伪随机数生成器驱动,输出不可预测。
对照的是 Math.random():它不是为安全设计的,其内部状态在观察到足够多的输出后可能被逆向推测。用 Math.random 生成的「随机」token 曾被用于攻击场景(例如猜测会话 ID、重置令牌)。
本工具优先用前者;只有在 API 不可用的极老浏览器里才降级,并会在界面上明确标出「⚠️ Math.random」,不会静默降级。
如果你的场景涉及安全(会话令牌、API Key、邀请码),请确认看到的是「✅ 密码学安全」。
UUID 里的连字符可以去掉吗?去掉会不会变成另一个 ID?
可以去掉,去掉前后是同一个 ID——连字符只是为了让 32 位十六进制更容易被眼睛分段,不携带任何信息。去掉后是 32 个连续的十六进制字符。
很多数据库为了节省空间会把它存成 16 字节的 BINARY(16) 而不是 36 字符的文本。
需要注意:去掉连字符后长度变了(36 → 32),如果你的数据库字段长度是按 36 设计的,直接存进去没问题;但如果后续要做字符串比较或当作主键,请保持格式统一,别一部分带连字符、一部分不带。
为什么 UUID v1 不直接用网卡 MAC 地址?
因为那是一个隐私漏洞。RFC 4122 最初的 v1 设计里,最后 12 位确实是机器的 MAC 地址,本意是保证分布式环境下不重复。
但 MAC 地址是硬件级唯一标识:把它写进 ID 里,任何拿到这个 ID 的人都能反查出你机器(或虚拟网卡)的网卡地址,进而可用于设备追踪。很多文档早就在提醒不要把 v1 暴露到公网。
所以现代实现普遍改用随机生成的 48 位节点值,并按规范把第一个字节的多播位(最低位)置 1,用来声明「这不是真实 MAC」。本工具就是这么做的。
代价是:与别的系统做 v1 互操作时,对方可能期望从节点位读出 MAC,这一点需要留意。

💬 留言板 0

全部留言需审核通过后展示
💬

还没有留言,来抢沙发吧!

✍️ 说点什么
0 / 500
图形验证码