我们在数据库设计中广泛使用GUID;业务对象属性为DB空值提供Guid.Empty GUID，如果值为null，则Guid.Empty始终保存到数据库。
除了Guid.Empty（00000000-0000-0000-0000-000000000000）之外，使用所有相同的字符e生成GUID的可能性有多大。 g。：11111111-1111-1111-1111-111111111111
只考虑将这些GUID用于特定值。
简而言之：对于根据已发布的标准和规范生成的GUID，它根本不可能发生。 GUID具有结构，并且一些字段实际上具有含义。更重要的是，.NET生成版本4的GUID，绝对不可能发生。它们的定义方式是不存在这样的GUID。有关详细信息，请参阅下文;-)
有五到七位是这里的主要陷阱。这些是版本标识符（第三部分的前四位）和变量字段，用于指定GUID的变体。
版本当前可以是1到5之间的任何值。因此，此时我们可以获得这样一个GUID的唯一有效十六进制数字显然是1到5。
让我们解剖一下versions：
8，9，A或B，所以无法工作。这与版本号的4相矛盾。到目前为止，我们排除第4版是不可能的，其他人则不太可能。让我们来看看变体字段。
variant field为向后兼容性指定了一些位模式（x是一个不关心），即：
0 x x Reserved. NCS backward compatibility.
1 0 x The only pattern that currently can appear
1 1 0 Reserved, Microsoft Corporation backward compatibility
1 1 1 Reserved for future definition.
由于此模式位于第四部分的开头，这意味着最高有效位始终设置为第四部分的第一个十六进制数字。这意味着这个数字永远不会是1，2，3或5。当然，不计算已生成的GUID。但MSB设置为0的那些恰好是v1或v2。而这些时间戳的一部分意味着它们将来必须产生一些千年才能实现。
正好有5,316,911,983,139,663,491,615,228,241,121,400,000种可能的组合，所以即使它的设计并不总是独一无二，但无论如何都有可能相当遥远。
与任何其他随机生成的guid相撞的可能性大约相同。所以，极不可能。
但是，您可能想要重新考虑使用guid来“存储”这样的数据。它们实际上用于唯一标识对象和组件。
GUID通常使用算法生成，而不是真正随机的十六进制字符串。如果您可以确定使用什么算法来生成它们，那么您可以确定要用作“幻数”的GUID是否会与生成的GUID发生冲突。
Wikipedia page on GUIDs有大量关于所用算法的信息，因此可以给你一个明确的答案。或者，在.net框架中的Guid.NewGuid（）方法上运行Reflector，虽然基于查看reference source for the method，这会调用CoCreateGuid in OLE32。
为什么要使用专门设计的GUID？除了可识别的方面，为什么不使用正确生成的GUID？ （你知道它会是独一无二的，这就是重点）
你的问题已经得到了回答，但我认为我在这里务实。
1）您只能使用此约定为自己提供8个“硬编码”选项。
2）您可以为每个“特殊”案例创建一个真正的GUID，而不是手动启动它们。这样，它保证是独一无二的，你将拥有超过8个。
我知道，这不是一个直接的答案，但考虑到你的意图，这可能是一个明智的建议。
非常非常低。 GUID格式包括识别该方案的几个位。如果您自己“生成”它们，那么GUID方案很可能是错误的。
对于我的上一家公司，我们使用guids作为我们所有数据库的表的主键。总之，我们实例化了超过1,000,000,000个对象，从未遇到任何问题。
它和任何其他Guid一样可能。 如果将其插入数据库中（即使具有一些特殊含义），那么您也可以确保它具有适当约束的唯一性。