安全
生成 UUID
v4 UUID 有 122 位随机数，两个独立生成的値实际上不可能相撞。随机性来自 crypto.getRandomValues，而不是 Math.random——后者可预测到足以对标识符构成真实风险。
点「生成」…
怎么用
- 选择需要几个。
- 按数据库字段要求勾选大写或「去掉连字符」。
- 点「生成」。
- 一次性复制整段结果。
不同版本不能随便换着用
v1 里嵌了时间戳和节点标识，等于泄露了这个 ID 是什么时候、在哪台机器上生成的，而且按顺序可以猜。v4 是 122 位纯随机，不携带任何信息。v7 是近年标准化的，把毫秒时间戳放在最前面、随机数放后面，于是 ID 既能按创建时间排序，又猜不出来。在它们之间选择是架构决策，不是格式偏好。
随机主键与索引碎片
用 v4 做主键，每次插入都落在 B 树索引的随机位置，会分裂页、让表逐渐膨胀。ULID 或 v7 这类时间有序的 ID 没有这个问题，因为新行总是追加在接近末尾的位置。代价是时间前缀对任何拿到 ID 的人可见——这一点值得在隐私评审时明说，而不是事后才发现。
ID 要进数据库时怎么选版本
UUIDv4 是 122 位随机数，排序毫无意义：作为对外的公开标识没问题，作为主键就很糟——每次插入都落在 B 树的一个随机位置，索引随之碎片化。UUIDv7 把毫秒时间戳放在高位，新行因此追加到索引末尾，而不是四处散落。
如果用的是 MySQL 的聚簇主键，这个差别值得在选型前实测：当表大到装不进内存之后，顺序插入通常比随机插入快好几倍。
常见问题
可以当数据库主键吗？
作为随机标识符没问题，无法被猜出，适合对外暴露的 ID。但它不是顺序的，会比特序自增整数更容易造成 B 树索引碎片——这是已知取舍，不是缺陷。
v1 和 v4 有什么区别？
v1 里嵌了时间戳和机器 MAC 地址，等于泄露了这个 ID 是什么时候、在哪台机器上生成的。v4 是纯随机，不携带任何信息。除非需要可按时间排序的 ID，否则用 v4。
两个 UUID 会重复吗？
每一对的碰撞概率约 2^122 分之一。按每秒生成十亿个算，也要一百年左右才可能撞上。
断网能用吗？
能，生成完全在本地。唯一要求是安全上下文，https 页面都满足。
两个 UUID 会撞吗？
v4 要生成约 2.7×1018 个，才有十亿分之一的重合概率。现实中，「生成器被重新播种」这种 bug 比真正碰撞常见得多。
UUID 放在 URL 里暴露安全吗？
安全——除了随机性它不携带任何信息。这正是它优于自增 ID 的原因：自增 ID 会泄露数据量，还让人能逐个枚举记录。