UUID 与随机字符串生成器

完全取决于版本，而版本就是第三组的第四个字符。version 4 是 122 个随机位；version 7 是毫秒时间戳加 74 个随机位；version 1 和 6 是时间戳、计数器加机器字段，完全没有随机性；version 3 和 5 是名称的哈希，知道名称的人可以完全预测。不看版本就信任一个标识符，正是许多人误以为它“天生随机”的原因。

version 4 的碰撞概率符合 122 个独立位的预期：每一对大约 2.3 × 10^18 分之一；按生日界估算，大约要生成 2^61 个值，碰撞才变得可能。这远远超出任何单一系统的生成量，所以没人需要协调 UUID：两台从不通信的机器不会产生同一个值。现实中的失败模式不是数学碰撞，而是随机源坏掉，那是另一个问题——也是这个页面从操作系统取值、而不用 `Math.random()` 的原因。

从技术上说，122 个随机位足够难以猜测，这不是弱点。问题在于 UUID 是标识符，所以会被记录：数据库行、请求日志、分析系统、错误报告和共享截图都会自然地带着它。出现在日志文件里的令牌，就是已经泄露的凭证。应该使用长度足够的随机字符串（这个页面也能生成），配上过期时间、单次使用和服务端记录，并让它远离会被记录进日志的 URL。

如果规模上来后插入必须快，选 version 7：时间戳位于最高有效位，值按创建时间排序，新行会追加到索引末尾，而不是散落各处。如果不希望公开一行的创建时间，选 version 4。version 7 的代价有限，但值得说清楚：每个值有 48 位是时钟读数，拿到它的人都能换算回一个时刻。对多数表来说这不是秘密，对某些表则是。两个选项在这里只差一次点击。

因为 version 1 和 6 以 48 位 node 字段结尾，最初的实现会填入网卡的 MAC 地址：这个值能识别厂商，并且在很长时间里是单台机器的稳定指纹。浏览器页面没有理由读取 MAC 地址，而往这个字段里写随机值，只会得到一个“看起来像真的、实际却不是”的 UUID。version 7 用另一种方式解决了同一个问题——按时间排序，又不必借用硬件地址。

取命名空间 UUID 的字节（RFC 9562 列出了 DNS、URL、OID 和 X.500 名称的标准命名空间），接上名称的字节，用 SHA-1 哈希，保留前 16 字节，然后把版本半字节设为 5，并设置变体位。这里不生成它，因为它并不随机——它的全部意义在于 `example.com` 永远得到同一个 UUID，这适合可重复的导入，却不适合任何需要保密的东西。算法很短，可以照规范实现；这个页面会很乐意把你算出的结果读回来，并告诉你它是 version 5。

不会。所有值都由你浏览器标签页里的 `crypto.getRandomValues` 生成，下载文件在本地构建，页面背后没有任何能够接收值的接口。静态 HTML 里的那批 UUID 是站点发布时生成一次的——那是在任何 JavaScript 运行之前你看到的内容，是真实示例而不是占位符。按下“重新生成”，页面上的每个值都会在你的设备上产生。

RFC 9562 定义了两个特殊值：nil UUID 全为零，max UUID 全为一。两者都不是标识符。它们在查询和范围判断里有用：nil 表示“这里什么都没有”，max 表示范围上界，这样写 `between` 查询时不必知道表里的最大值。这里的检查模式能识别两者并明确说明，因为用全零做行键通常意味着缺陷，而不是有意为之。