为了获得更好的结果，最好的方法是将GUID与时间戳附加在一起(只是为了确保它保持唯一)

Guid.NewGuid().ToString() + DateTime.Now.ToString();

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

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

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

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

http://usecuid.org/

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

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

简单的答案是肯定的。

Raymond Chen写了一篇关于guid和为什么guid的子字符串不能保证唯一的文章。这篇文章深入探讨了guid的生成方式以及它们用来确保唯一性的数据，这应该会花一些篇幅来解释它们为什么会这样:-)

I think that when people bury their thoughts and fears in statistics, they tend to forget the obvious. If a system is truly random, then the result you are least likely to expect (all ones, say) is equally as likely as any other unexpected value (all zeros, say). Neither fact prevents these occurring in succession, nor within the first pair of samples (even though that would be statistically "truly shocking"). And that's the problem with measuring chance: it ignores criticality (and rotten luck) entirely.

如果真的发生了，结果是什么?你的软件停止工作了吗?有人受伤了吗?有人死了吗?世界会爆炸吗?

临界性越极端，“概率”这个词就越难听。最后，链接guid(或XORing它们，或其他什么)是当你(主观地)认为你的特定临界性(和你的“幸运”感觉)是不可接受的时候所做的事情。如果它能毁灭世界，那么请代表我们所有没有参与大型强子对撞机核试验的人，不要使用guid或任何其他不确定的东西!

GUID代表全局唯一标识符

简而言之: (线索就在名字里)

详细: guid被设计为唯一的;它们是使用基于计算机时钟和计算机本身的随机方法计算的，如果你在同一毫秒内在同一台机器上创建多个guid，它们可能是匹配的，但对于几乎所有的正常操作，它们应该被认为是唯一的。