TL；DR:DocumentDB自动生成的ID应该是GUID还是UUID，实际上有区别吗？如果它们是UUID，那么UUID的哪个变体/版本？
背景：如果您不提供ID，某些DocumentDB客户端库将自动为您生成ID。我在Azure博客和几个相关问题中看到过，生成的ID是GUID。我知道有一些关于GUID是否是UUID的讨论，很多人说它们是。
问题：然而，我注意到DocumentDB自动生成的一些ID不遵循UUID RFC，它只允许"中的数字1-5；版本"；半字节(xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx中的V(。DocumentDB生成具有该半字节中任何十六进制数字的ID，例如d981befd-d19b-ee48-35bd-c1b507d3ec4f，其版本半字节是ee48的第一个e。
这可能取决于使用哪个客户端来创建文档。在我们的DocumentDB数据库中，我们有第三组为dde5、627a、fe95等的文档。这些文档是通过使用选项{'disableAutomaticIdGeneration': false}调用Collection.createDocument()从存储过程中存储的。我通过第三方DocumentDBStudio应用程序创建的其他文档在第三组中总是有4xxx，这是一个有效的UUID版本。但是，我通过Azure门户创建的文档具有非标准的第三组，如b359。
问题：自动生成的DocumentDB ID应该是GUID还是UUID，实际上有区别吗？如果是UUID，那么是哪个变体？
仔细查看GitHub上的源代码，我发现各种客户端和服务器端库使用几种不同的方法来创建它们所称的GUID(在某些库中(或UUID(在其他库中(。
nodejs客户端、Javascript客户端和服务器端库通过连接一系列十六进制数字和连字符来制造他们所称的GUID。请注意，这些是随机的，但不符合创建RFC4122版本4 UUID的规则。
Python客户端和Java客户端调用各自的标准库方法来生成随机(版本4(UUID。
.NET客户端可以通过NuGet获得，但源代码尚未发布。
摘要：
- Microsoft在其客户端库中没有区分GUID和UUID。他们交替使用这些术语
- GUID:UUID的结果取决于创建文档时用于调用DocumentDB的客户端库