UUID（通用唯一识别码） 是 128 位的全局唯一标识符，按 RFC 4122 / RFC 9562 标准排成 36 字符的字符串。本工具在浏览器本地生成，不上传也不依赖任何服务，覆盖 v4 / v7 / v1 / v3 / v5 / NIL 六种主流版本，支持批量 1–1000 条、格式定制和 UUID 解析校验。
| 版本 | 生成方式 | 适用场景 |
|---|---|---|
| v4 | 122 位随机 | 通用 ID、文件名、trace ID（最常用） |
| v7 | 48 位毫秒时间戳 + 74 位随机 | 数据库主键（按时间有序，索引友好） |
| v1 | 时间 + 节点 ID | 老系统兼容，浏览器环境节点 ID 是伪 MAC |
| v3 | MD5(namespace + name) | 确定性映射（推荐用 v5 替代） |
| v5 | SHA-1(namespace + name) | 把外部字符串 ID 哈希成本系统 UUID |
| NIL | 全零 | 占位符 / “无值”标识 |
PostgreSQL、MySQL 这些关系数据库的主键索引是 B+ 树，v4 完全随机，每次插入落点四处分散，频繁触发页分裂、写放大、缓存命中差。v7 按时间单调递增，新插入永远落在树的最右边，几乎只写最后一页——这就是 ULID / Snowflake / KSUID 早就在做的事，v7 把它纳入 RFC 标准（RFC 9562, 2024）。如果你的表 ID 列还是 v4，迁到 v7 是几乎零成本的写入性能优化。
uuid 类型仍按 16 字节存，省的只是字符串展示长度）。{...}：Windows COM / 注册表 / .NET Guid.ToString("B") 风格。工具完全在浏览器跑（基于 npm 包 uuid v9+），不发起任何网络请求，UUID 不会上传到任何服务器。批量 1000 条在普通笔记本上耗时 <50ms。
给数据库做主键就用 v7，其它场景默认 v4。v4 是纯随机，无序；v7 前 48 位是 Unix 毫秒时间戳，按生成顺序天然递增，B+ 树索引插入时几乎只写最后一页，比 v4 的随机插入页分裂少得多。前端临时 ID、文件名、trace ID 用 v4 就够。
实际工程中可以当作不会。v4 有 122 位随机，按生日攻击估算，每秒生成 10 亿个、连生 85 年才有 50% 概率撞一次——常规业务量级远碰不到。v7 因为前 48 位是时间戳，只有同一毫秒内同时生成才有可能撞上后 74 位随机。NIL（全 0）是唯一会主动撞的情况，仅作占位符。
确定性 UUID：输入"命名空间 + 名称"，输出永远是同一个 UUID。v3 用 MD5、v5 用 SHA-1，能用 v5 就用 v5。典型用途：把外部系统的字符串 ID（域名、URL、租户名）映射成本系统主键，同样的输入生成同样的 UUID，免去维护映射表。命名空间用 RFC 4122 预定义的 DNS / URL / OID / X500 即可。
比想象中安全。RFC 早期定义 v1 用 MAC 地址当节点 ID，担心泄露设备身份；但浏览器环境拿不到 MAC，uuid 库会用随机字节冒充节点 ID（首字节最低位置 1 表明是"伪 MAC"）。剩下的隐私问题是时间戳暴露生成时刻——如果你不想让别人看出 UUID 是几点生成的，别用 v1 / v7，改用 v4。
crypto.randomUUID() 不就行了吗？只够用 v4。浏览器原生 crypto.randomUUID() 自 2022 年后全面支持，等价于本工具的 v4 模式。但它只生成 v4，没有 v7（时间序）、v3 / v5（确定性）、v1（基于时间）这些版本。如果只需要 v4 单条生成，浏览器原生就够；批量生成、版本切换、格式定制还是工具方便。
标准 UUID 36 个字符（32 hex + 4 个 -），结构是 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx。M 位是版本号（1/3/4/5/7），N 位的高几位是 variant（标准 RFC 4122 是 10xx，所以 N 范围 8/9/a/b）。其余位的含义随版本不同：v4 全是随机数，v7 前 12 位是毫秒时间戳，v1 是按字段拆出的时间 + 节点 ID。