CodeKitHub工具介绍
UUID（通用唯一标识符）是一个 128 位的标识符，写成 36 个字符，例如 550e8400-e29b-41d4-a716-446655440000。v4 版本完全由随机数据生成，碰撞概率低到可以忽略：即使每秒生成十亿个，持续几十年才可能出现重复。
UUID 广泛用于数据库主键、链路追踪的请求 ID、文件名、API 密钥，以及任何不需要中心机构协调就能保证唯一的场景。
UUID 的标准是 RFC 4122，2024 年修订为 RFC 9562——修订版保持 v4 不变，并新增了 UUIDv7：一种按时间戳排序的变体，用作数据库主键时索引性能更好。
为什么使用它？
- 加密级安全：使用 crypto.randomUUID()，而不是弱随机的 Math.random()。
- 批量生成——一次最多 500 个，每行一个，直接可用。
- 支持大写、去连字符，适配不同系统的格式要求。
- 浏览器本地生成，可离线使用，UUID 不会被发送到任何地方。
- 免费、即时、无需登录。
使用方法
- 选择需要生成的数量（1–500）。
- 按需勾选"大写"或"去掉连字符"。
- 点"生成 UUID"。
- 点"复制全部"复制整个列表。
示例
输入
数量: 3输出
f47ac10b-58cc-4372-a567-0e02b2c3d479
9c858901-8a57-4791-81fe-4c455b099bc9
16fd2706-8baf-433b-82eb-8c7fada847da每个 UUID 都由安全随机数独立生成。
常见使用场景
- 数据库主键：可以在插入数据前就先生成好合法ID，适合离线优先的应用，或者客户端需要在服务器确认之前就引用某条记录的场景。
- 分布式系统：多台服务器可以各自独立生成ID，不需要协调，也不会碰撞——不像自增整数ID那样需要一个统一的数据源。
- 幂等键：重试API请求时带上同一个UUID，服务器可以识别并安全忽略重复提交。
- 测试数据和种子数据：一次批量生成几百个唯一ID，用来填充测试数据库或模拟API返回。
- React/Vue列表的key：列表项还没有天然唯一ID时，生成的UUID在开发阶段可以当作稳定的key使用。
需要知道的局限
UUID不能按创建时间排序——v4的随机性意味着新生成的ID在数据库索引里不会相邻排列，规模大了会影响插入性能（这正是v7版本存在的原因——按时间排序的随机UUID）。如果既需要按时间排序又要唯一性，v7或者雪花算法（Snowflake）风格的ID会比v4更合适。
单独的UUID不是安全凭证。它的"不可预测"只是说你没法从一个UUID推算出另一个，但它从设计上就没有真正的身份令牌需要的审计、过期、吊销这些功能——这类场景请用专门的会话/API令牌方案。
随机性到底是怎么来的
v4 UUID有122位是真正随机的（另外6位按RFC 4122规范固定，用来标记版本号和变体）。本工具通过浏览器的Web Crypto API调用crypto.getRandomValues()来获取这个随机性——这和TLS密钥等加密操作用的是同一个底层随机源，而不是弱得多、可被预测的Math.random()（一些早期基于Math.random()构建的UUID库就曾被指出生成的ID可被猜测）。
把碰撞概率换算成具体数字：122位随机数意味着要生成大约271亿亿（2.71×10^18）个UUID，才有50%的概率出现一次碰撞——比任何单个应用实际会生成的数量高出好几个数量级。这正是为什么v4 UUID在实践中被当作"事实上不会碰撞"，尽管数学上并非绝对不可能。
常见问题
两个 UUID 会重复吗？
理论上可能，实际上不会。v4 UUID 有 122 位随机数据，即使生成数万亿个，碰撞概率仍然可以忽略不计，完全可以当作唯一值使用。
UUID 各版本有什么区别？
v1 基于时间戳和网卡 MAC 地址（会泄露信息）；v4 完全随机（最常用）；v5 由名称哈希派生（结果确定）；v7 是按时间排序的随机 UUID（适合数据库索引）。本工具生成 v4。
用 UUID 做令牌安全吗？
本工具使用加密级随机源，远好于 Math.random()。作为标识符完全够用；如果是会话令牌等高安全场景，建议使用专门的、熵更大的令牌生成方案。
UUID 和 GUID 一样吗？
一样。GUID（全局唯一标识符）是微软对同一种 128 位格式的叫法，两个词可以互换使用。
生成的 UUID 会被记录吗？
不会。生成完全在浏览器本地进行，不传输、不存储、不记录——你看到的每个 UUID 只存在于你的屏幕上。