如果你的系统时钟设置正确，没有被环绕，如果你的网卡有自己的MAC(即你没有设置自定义MAC)，你的网卡供应商没有回收MAC(他们不应该这样做，但已经知道发生了)，如果你的系统的GUID生成功能正确实现，那么你的系统将永远不会生成重复的GUID。

如果地球上每个生成guid的人都遵循这些规则，那么您的guid将是全局唯一的。

在实践中，违反规则的人数很少，他们的guid不太可能“逃脱”。冲突在统计上是不可能发生的。

从统计上看，向导是独一无二的。两个不同的客户端生成相同Guid的几率非常小(假设Guid生成代码中没有错误)。你也可以担心由于宇宙射线导致的处理器故障，并决定今天2+2=5。

分配新guid的多个线程将获得唯一的值，但您应该知道您正在调用的函数是线程安全的。这是在哪个环境中?

GUID算法通常根据v4 GUID规范实现，它本质上是一个伪随机字符串。可悲的是，这些都属于“可能非唯一”的类别，来自维基百科(我不知道为什么这么多人忽略了这一点):“……其他GUID版本有不同的唯一性属性和概率，从保证唯一性到可能的非唯一性。”

V8的JavaScript Math.random()的伪随机属性在唯一性方面很糟糕，通常在几千次迭代之后就会发生冲突，但V8并不是唯一的罪魁祸首。我曾经使用PHP和Ruby实现的v4 GUID在现实世界中遇到过GUID冲突。

因为在多个客户端和服务器集群上扩展ID生成变得越来越普遍，熵会受到很大的冲击——使用相同的随机种子生成ID的几率会增加(在伪随机生成器中，时间经常被用作随机种子)，GUID冲突也会从“可能不是唯一的”升级为“很可能造成很多麻烦”。

为了解决这个问题，我开始创建一个可以安全扩展的ID算法，并更好地保证不发生碰撞。它通过使用时间戳、内存中的客户端计数器、客户端指纹和随机字符来实现这一点。这些因素的组合产生了一种附加的复杂性，它特别抗碰撞，即使你将它扩展到多个主机:

http://usecuid.org/

Eric Lippert写了一系列关于guid的非常有趣的文章。

There are on the order 230 personal computers in the world (and of course lots of hand-held devices or non-PC computing devices that have more or less the same levels of computing power, but lets ignore those). Let's assume that we put all those PCs in the world to the task of generating GUIDs; if each one can generate, say, 220 GUIDs per second then after only about 272 seconds -- one hundred and fifty trillion years -- you'll have a very high chance of generating a collision with your specific GUID. And the odds of collision get pretty good after only thirty trillion years.

GUID指南，第一部分 GUID指南，第二部分 GUID指南，第三部分

MSDN:

新Guid的值全为零或等于任何其他Guid的概率非常低。

“GUID是100%唯一的吗?”的答案是“不是”。

如果你想要GUID的100%唯一性，然后做下面的事情。 生成GUID 检查GUID是否存在于您正在寻找唯一性的表列中 如果存在，则转步骤1，否则转步骤4 使用这个GUID作为唯一的。