这个问题的答案很大程度上取决于UUID版本。

许多UUID生成器使用版本4的随机数。然而，其中许多使用伪随机数生成器来生成它们。

如果使用一个短周期的低种子PRNG来生成UUID，我认为这一点都不安全。一些随机数生成器的方差也很差。也就是说，更倾向于某些数字。这不会有好结果的。

因此，它的安全性取决于生成它的算法。

另一方面，如果您知道这些问题的答案，那么我认为使用版本4的uuid应该是非常安全的。事实上，我正在使用它来识别网络块文件系统上的块，到目前为止还没有发生冲突。

在我的情况下，我使用的PRNG是一个梅森龙卷风，我很小心，它的播种方式是来自多个来源，包括/dev/ urrandom。梅森龙卷风的周期为2^19937−1。在我看到一个重复的uuid之前，会有很长很长的时间。

因此，选择一个好的库或自己生成它，并确保使用合适的PRNG算法。

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

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

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

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

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

这个问题的答案很大程度上取决于UUID版本。

许多UUID生成器使用版本4的随机数。然而，其中许多使用伪随机数生成器来生成它们。

如果使用一个短周期的低种子PRNG来生成UUID，我认为这一点都不安全。一些随机数生成器的方差也很差。也就是说，更倾向于某些数字。这不会有好结果的。

因此，它的安全性取决于生成它的算法。

另一方面，如果您知道这些问题的答案，那么我认为使用版本4的uuid应该是非常安全的。事实上，我正在使用它来识别网络块文件系统上的块，到目前为止还没有发生冲突。

在我的情况下，我使用的PRNG是一个梅森龙卷风，我很小心，它的播种方式是来自多个来源，包括/dev/ urrandom。梅森龙卷风的周期为2^19937−1。在我看到一个重复的uuid之前，会有很长很长的时间。

因此，选择一个好的库或自己生成它，并确保使用合适的PRNG算法。

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

对于UUID4，我认为在一个边长360000公里的立方体盒子中，id的数量大约与沙粒的数量相同。这是一个边长约为木星直径2.5倍的盒子。

如果我搞砸了单位，就会有人告诉我:

沙粒体积0.00947mm^3 (Guardian) UUID4有122个随机位-> 5.3e36可能的值(维基百科) 那么多沙粒的体积= 5.0191e34 mm^3或5.0191e+25m^3 体积= 3.69E8m或369,000km的立方箱的边长 木星直径:139,820公里(谷歌)