tl；dr:由documentdb自动生成的ID应该是guid或uuid，实际上有什么区别吗？如果它们是uuid，那么uuid的哪个变体/版本？

背景：如果不提供ID，一些documentdb客户机库将自动为您生成一个ID。我在Azure博客和几个相关问题中看到过它提到，生成的ID是guid。我知道有人在讨论guid是否是uuid，很多人都说是。

问题：但是，我注意到documentdb auto生成的一些ID没有遵循uuid rfc，它只允许"version"nibble中的数字1-5(V在xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx中)。documentdb用该半字节中的任何十六进制数字生成id，例如d981befd-d19b-ee48-35bd-c1b507d3ec4f，其版本nibble是ee48的第一个e。

这可能取决于使用哪个客户机来创建文档。在我们的documentdb数据库中，我们有第三组dde5、627a、fe95等文档。这些文档通过使用选项{'disableAutomaticIdGeneration': false}调用Collection.createDocument()，从存储过程中存储。我通过第三方documentdb studio应用程序创建的其他文档在第三组中总是有4xxx，这是一个有效的uuid版本。但是，我通过Azure门户创建的文档具有非标准的第三组，如b359。

问题：自动生成的documentdb id应该是guid还是uuid，实际上有区别吗？如果是UUID，那么是哪种变体？

在Github的源代码中，我发现不同的客户机和服务器端库使用几种不同的方法来创建它们所调用的guid(在某些库中)或uuid(在其他库中)。

nodejs客户机、javascript客户机和服务器端库通过连接一系列十六进制数字和连字符来生成它们所称的guid。请注意，这些是随机的，但不符合创建RFC4122版本4 UUID的规则。

Python客户端和Java客户端调用它们各自的标准库方法来生成一个随机(版本4)UUID。

.NET客户端通过nuget可用，但源代码尚未发布。

总结：

• 微软并没有在客户端库中区分guid和uuid。他们正在交替使用这些术语。
• guid/uuid的使用取决于在创建文档时使用哪个客户端库来调用documentdb。