如果你所说的“有足够的时间”是指100年，你以每秒10亿的速度创造它们，那么是的，100年后你有50%的几率发生碰撞。

UUID类型不止一种，因此“安全程度”取决于您使用的类型(UUID规范称为“版本”)。

Version 1 is the time based plus MAC address UUID. The 128-bits contains 48-bits for the network card's MAC address (which is uniquely assigned by the manufacturer) and a 60-bit clock with a resolution of 100 nanoseconds. That clock wraps in 3603 A.D. so these UUIDs are safe at least until then (unless you need more than 10 million new UUIDs per second or someone clones your network card). I say "at least" because the clock starts at 15 October 1582, so you have about 400 years after the clock wraps before there is even a small possibility of duplications. Version 4 is the random number UUID. There's six fixed bits and the rest of the UUID is 122-bits of randomness. See Wikipedia or other analysis that describe how very unlikely a duplicate is. Version 3 is uses MD5 and Version 5 uses SHA-1 to create those 122-bits, instead of a random or pseudo-random number generator. So in terms of safety it is like Version 4 being a statistical issue (as long as you make sure what the digest algorithm is processing is always unique). Version 2 is similar to Version 1, but with a smaller clock so it is going to wrap around much sooner. But since Version 2 UUIDs are for DCE, you shouldn't be using these.

所以对于所有实际问题，它们都是安全的。如果你不喜欢把它留给概率(例如，你是那种担心地球在你的一生中被一颗大小行星摧毁的人)，只要确保你使用版本1的UUID，并且它保证是唯一的(在你的一生中，除非你计划活到公元3603年以后)。

那么，为什么不是每个人都使用版本1的uuid呢?这是因为版本1的uuid揭示了生成它的机器的MAC地址，并且它们是可以预测的——这两件事可能会对使用这些uuid的应用程序产生安全影响。

对于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公里(谷歌)

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

很安全:

一个人被陨石击中的年风险是 估计是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月的修订版，在编辑重新编辑该部分之前)。

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

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

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

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

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

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

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

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