UUID 生成器

UUID 是 128 位标识符，通常显示为 32 个十六进制数字组成的 8-4-4-4-12 结构。v4 用加密安全随机字节填充随机字段，适合不希望暴露创建顺序的常规标识符。v7 会把 Unix 毫秒时间戳放在前部，后面保留随机数据，因此生成值大致按创建时间排序，在保持无需中心计数器的同时，可能改善数据库索引局部性。

生成 UUID 不需要查询统一注册表。唯一性来自极大的数值空间：符合规范的 v4 UUID 在版本与变体标记之外仍有 122 个随机位，普通应用规模下意外碰撞概率极低；v7 则组合时间与随机位。但两种格式都不是秘密、认证令牌或身份证明。除非有独立授权层保护对应对象，否则应把 UUID 当作公开标识符。

当顺序无关、需要不透明记录 ID 或请求关联 ID 时选择 v4；新数据库主键需要时间排序和更好的索引写入行为时，可以在确认语言与数据库库支持后选择 v7。你可以在这里生成少量值用于测试数据、API 示例、迁移脚本和手动测试。生产代码应在记录创建时由应用内部生成，不应长期依赖从网页复制的预生成列表。

规范文本形式使用小写十六进制字符和连字符。第三组的第一个十六进制数字表示版本：v4 为 4，v7 为 7；第四组第一个数字编码 RFC 变体，通常是 8、9、a 或 b。外形匹配并不代表值可信，验证时既要检查语法，也要检查允许的版本，并且仍需单独执行授权判断。

• 生成的 UUID 会发送给 TmpKit 吗？——不会，它们在本地生成，网站不会记录。
• 可以把 UUID 当作密码或 API 密钥吗？——不可以。标识符不是凭据，而且 v7 会主动暴露大致创建时间。
• 应该选哪个版本？——需要不透明随机值时使用 v4；需要对数据库友好的时间排序标识符时考虑 v7。
• 可能发生碰撞吗？——数学上可能，但正确生成时概率极低；应用仍应设置唯一约束。