在多线程/多进程单元测试期间，我经历过guid不是唯一的(也是?)我想这与所有其他条件相同的情况下，伪随机生成器的相同播种(或缺乏播种)有关。我用它来生成唯一的文件名。我发现操作系统在这方面做得更好:)

恶意破坏预警

你问guid是否100%唯一。这取决于它在guid中必须是唯一的。当guid的数量接近无穷大时，重复guid的概率接近100%。

从http://www.guidgenerator.com/online-guid-generator.aspx

What is a GUID? GUID (or UUID) is an acronym for 'Globally Unique Identifier' (or 'Universally Unique Identifier'). It is a 128-bit integer number used to identify resources. The term GUID is generally used by developers working with Microsoft technologies, while UUID is used everywhere else. How unique is a GUID? 128-bits is big enough and the generation algorithm is unique enough that if 1,000,000,000 GUIDs per second were generated for 1 year the probability of a duplicate would be only 50%. Or if every human on Earth generated 600,000,000 GUIDs there would only be a 50% probability of a duplicate.

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

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

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

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

http://usecuid.org/

而每个生成的GUID不是 保证是唯一的，总数 唯一键数(2128或 3.4×1038)是如此之大，相同的数字的概率是 生成两次是非常小的。为 例如，考虑可观察对象 宇宙，其中包含约5×1022 星星;每颗恒星都有可能 6.8×1015通用唯一的guid。

从维基百科。

这是一些关于如何创建GUID(用于。net)以及如何在正确的情况下获得相同的GUID的好文章。

https://ericlippert.com/2012/04/24/guid-guide-part-one/

https://ericlippert.com/2012/04/30/guid-guide-part-two/

https://ericlippert.com/2012/05/07/guid-guide-part-three/

​​

最难的部分不是生成重复的Guid。

最难的部分是设计一个数据库来存储所有生成的数据，以检查它是否实际上是重复的。

从维基:

例如，为了有至少一次碰撞的50%概率，需要生成的随机版本4 uuid的数量为2.71 quintillion，计算如下:

在这里输入图像描述

这个数字相当于在大约85年的时间里每秒生成10亿个UUID，而包含这么多UUID的文件(每个UUID 16个字节)大约是45艾字节，比目前存在的最大数据库(几百pb量级)大很多倍

是的，GUID应该总是唯一的。它是基于硬件和时间，加上一些额外的位，以确保它是唯一的。我相信理论上有可能得到两个一模一样的，但在现实场景中极不可能。

以下是Raymond Chen关于Guids的一篇很棒的文章:

https://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx ​ ​ ​