我已经做了很多年了。永远不要遇到问题。

我通常设置我的数据库有一个表，其中包含所有的键和修改的日期等。我从没遇到过钥匙重复的问题。

它的唯一缺点是，当您编写一些查询来快速查找一些信息时，您需要进行大量的复制和粘贴键。你不再有简单易记的id了。

很安全:

一个人被陨石击中的年风险是 估计是170亿分之一的几率，也就是说 概率约为0.00000000006 (6 × 10−11)，相当于几率 在一年内创造出几十万亿uuid，并拥有一个uuid 复制。换句话说，只有在每次生成10亿个uuid之后 第二，在接下来的100年里，只创造一个的概率 重复率约为50%。

警告:

However, these probabilities only hold when the UUIDs are generated using sufficient entropy. Otherwise, the probability of duplicates could be significantly higher, since the statistical dispersion might be lower. Where unique identifiers are required for distributed applications, so that UUIDs do not clash even when data from many devices is merged, the randomness of the seeds and generators used on every device must be reliable for the life of the application. Where this is not feasible, RFC4122 recommends using a namespace variant instead.

来源:维基百科关于通用唯一标识符的文章的随机UUID重复概率部分(链接指向2016年12月的修订版，在编辑重新编辑该部分之前)。

另请参阅同一篇通用唯一标识符文章中关于同一主题的当前部分，碰撞。

我已经做了很多年了。永远不要遇到问题。

我通常设置我的数据库有一个表，其中包含所有的键和修改的日期等。我从没遇到过钥匙重复的问题。

它的唯一缺点是，当您编写一些查询来快速查找一些信息时，您需要进行大量的复制和粘贴键。你不再有简单易记的id了。

我应该提一下，我在亚马逊上买了两个外接希捷驱动器，它们有相同的设备UUID，但PARTUUID不同。大概他们用来格式化硬盘的克隆软件也复制了UUID。

显然，UUID冲突更可能是由于有缺陷的克隆或复制过程而不是由于随机巧合而发生。在计算UUID风险时请记住这一点。

我不知道这对您是否重要，但请记住，guid是全局惟一的，但guid的子字符串不是。

UUID方案通常不仅使用伪随机元素，还使用当前系统时间和某种通常唯一的硬件ID(如果可用的话)，比如网络MAC地址。

使用UUID的关键在于，您相信它能够比您自己更好地提供唯一的ID。这与使用第三方加密库而不是自己开发加密库的原理相同。自己做可能更有趣，但这样做通常不那么负责任。