甚至值得检查一下Guid.NewGuid（）是否为Guid.Empty吗？

在其中一个项目中，我经常遵循以下模式进行工作：

var guid = Guid.NewGuid().ToString();
while (guid == Guid.Empty.ToString())
{
    guid = Guid.NewGuid().ToString();
}

虽然我知道不能保证 GUID是唯一的，并且根据MSDN文档，生成的GUID可能为零，但这是否是一个实际的考虑因素，实际上值得在计算意义上以及针对开发人员的角度进行周期测试？

我认为不值得检查Guid.Empty。Guid.NewGuid的文档出于某种原因提到

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

Guid.NewGuid是Win32 API CoCreateGuid的包装，它没有提到返回所有零。

Raymond Chen 走得更远，建议

没有有效的CoCreateGuid实现可以生成GUID_NULL

所以，不，我不会担心。我不会猜测Guid.NewGuid文档为什么会提到它。

如果您发现Guid.NewGuid() == Guid.Empty自己赢得了地球上最艰难的彩票。不要打扰任何唯一性或冲突检查。不必做什么的GUID 的。我会为您节省数学的时间，它在网络上无处不在。

此外，Windows guid始终具有一个等于的“数字” 4。有一些指导结构。

您发布的代码片段看起来像一个开发人员忘记了初始化Guid变量而发现它是Guid.Empty。他错误地确定Guid.NewGuid()了原因。现在，他将永远迷信这一点。

无论如何，这是一个错误的问题。我确信您的代码不仅不依赖于绘图，Guid.Empty而且还依赖于唯一性。该while循环不会强制唯一性。指导在没有协调的情况下产生独特的价值。那就是他们的用例。

查看method的源代码Guid.NewGuid：

public static Guid NewGuid() {
    Contract.Ensures(Contract.Result<Guid>() != Guid.Empty);
    ...
}

看到代码合同了吗？该Guid.NewGuid方法永远不会提供空的GUID。

如果要针对零GUID检查GUID，则根据相同的逻辑，您还需要进行尽职调查，以针对应用程序中的所有其他GUID进行检查（因为获得零的概率应与针对GUID的概率相同）。在您的应用中获取其他GUID *）。您需要执行此操作以证明您所作用的公理是该GUID是唯一的（实际上与test相对于0是相同的公理）。

显然，这样做是荒谬的。

TLDR；如果您可以信任NewGuid（）来产生唯一的结果，则也可以信任它不产生任何已知的GUID。

*实际上与.NET GUID总是不同的概率不相同，{________-____-4___-____-____________}因此NewGuid永远不会生成零GUID

只是为了好玩，我建议对此处的文档进行改进：http : //feedback.msdn.com/forums/257782-msdn-feature-suggestions/suggestions/7143498-fix-documentation-for-newguid