我经历了一个重复的GUID。

我使用的是Neat收据桌面扫描仪，它自带专有数据库软件。该软件有一个同步到云的功能，我总是在同步时得到一个错误。浏览一下日志，你会发现这句话非常棒:

"errors":[{"code":1，"message":"creator_guid: is already . 了”、“guid”:“c83e5734 d77a - 4 - b09 b8c1 - 9623 cac7b167”}]}

我有点难以置信，但可以肯定的是，当我找到进入本地网络数据库的方法并删除包含该GUID的记录时，错误就停止了。

所以用轶事证据来回答你的问题，没有。副本是可能的。但它发生的原因很可能不是由于偶然，而是由于标准的做法在某种程度上没有得到遵守。(我只是没有那么幸运)然而，我不能肯定。这不是我的软件。

他们的客户支持非常有礼貌和乐于助人，但他们以前肯定从未遇到过这个问题，因为在与他们电话交谈3个多小时后，他们没有找到解决方案。(总之，Neat给我留下了深刻的印象，这个小故障虽然令人沮丧，但并没有改变我对他们产品的看法。)

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

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

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

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

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

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

恶意破坏预警

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

在更广泛的意义上，这被称为“生日问题”或“生日悖论”。维基百科有一个很好的概述: 维基百科-生日问题

粗略地说，池大小的平方根是一个粗略的近似值，即您可以期望有50%的重复机会。这篇文章包含了一个关于池大小和各种概率的概率表，包括2^128的一行。所以对于1%的碰撞概率，你可以随机选择2.6*10^18个128位数字。50%的概率需要2.2*10^19次选择，而根号(2^128)是1.8*10^19次选择。

当然，这只是一个真正随机过程的理想情况。正如其他人所提到的，很多事情都取决于随机方面——生成器和种子有多好?如果有一些硬件支持来帮助这个过程，那就太好了，这将更加防弹，除非任何东西都可能被欺骗或虚拟化。我怀疑这可能是MAC地址/时间戳不再被合并的原因。

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

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