这是一个很普遍的问题。一个答案是:“这取决于您希望生成什么样的UUID”。但一个更好的问题是:“在我回答之前，你能告诉我们为什么你需要编写自己的UUID生成算法，而不是调用大多数现代操作系统提供的UUID生成功能吗?”

这样做更容易、更安全，而且由于您可能不需要自己生成，为什么要费心编写实现呢?在这种情况下，答案就是使用你的O/S、编程语言或框架提供的任何东西。例如，在Windows中，有CoCreateGuid或UuidCreate，或者从众多正在使用的框架中可用的各种包装器之一。在Linux中有uuid_generate。

如果出于某种原因，您绝对需要生成自己的uuid，那么至少要明智地避免生成v1和v2 uuid。要做到这一点是很棘手的。相反，坚持使用v3、v4或v5 uuid。

更新: 在评论中，您提到您正在使用Python并链接到此。查看提供的接口，对您来说最简单的选择是通过调用UUID .uuid4()来生成一个v4 UUID(即从随机数据创建的UUID)。

如果您有一些需要(或可以)散列以从中生成UUID的数据，那么您可以使用v3(依赖于MD5)或v5(依赖于SHA1)。生成v3或v5 UUID很简单:首先选择您想要生成的UUID类型(您可能应该选择v5)，然后选择适当的名称空间，并使用您想要用于生成UUID的数据调用函数。例如，如果你正在哈希一个URL，你可以使用NAMESPACE_URL:

uuid.uuid3 (uuid。NAMESPACE_URL, ' https://ripple.com ')

请注意，这个UUID将不同于相同URL的v5 UUID，后者是这样生成的:

uuid.uuid5 (uuid。NAMESPACE_URL, ' https://ripple.com ')

A nice property of v3 and v5 URLs is that they should be interoperable between implementations. In other words, if two different systems are using an implementation that complies with RFC4122, they will (or at least should) both generate the same UUID if all other things are equal (i.e. generating the same version UUID, with the same namespace and the same data). This property can be very helpful in some situations (especially in content-addressible storage scenarios), but perhaps not in your particular case.

Postgres文档描述了uuid之间的差异。其中有几个:

V3:

uuid_generate_v3(命名空间uuid，名称文本)——该函数使用指定的输入名称在给定的命名空间中生成版本3的uuid。

V4:

uuid_generate_v4——这个函数生成一个版本4的UUID，它完全由随机数派生。

如果需要随机数，请使用随机数库。如果你想要一个有效0.00的唯一标识符…这里还有很多0…001%的碰撞概率，您应该使用UUIDv1。关于UUIDv3和v5，请参阅Nick的帖子。

UUIDv1不安全。这不是命中注定的。这意味着它是唯一的，而不是不可猜测的。UUIDv1使用当前时间戳，加上一个机器标识符，再加上一些随机的东西来生成一个永远不会再由该算法生成的数字。这适用于事务ID(即使每个人都在处理数百万事务/秒)。

To be honest, I don't understand why UUIDv4 exists... from reading RFC4122, it looks like that version does NOT eliminate possibility of collisions. It is just a random number generator. If that is true, than you have a very GOOD chance of two machines in the world eventually creating the same "UUID"v4 (quotes because there isn't a mechanism for guaranteeing U.niversal U.niqueness). In that situation, I don't think that algorithm belongs in a RFC describing methods for generating unique values. It would belong in a RFC about generating randomness. For a set of random numbers:

chance_of_collision = 1 - (set_size! / (set_size - tries)!) / (set_size ^ tries)

版本1:使用时间戳和单调计数器的uuid。 版本3:基于某些数据的MD5哈希的uuid。 版本4:带有随机数据的uuid。 版本5:基于某些数据的SHA1哈希的uuid。 版本6:使用时间戳和单调计数器的uuid。 版本7:使用Unix时间戳的uuid。 版本8:使用用户定义数据的uuid。

阅读Rust文档。

生成UUID有两种不同的方法。

如果只需要唯一的ID，则需要版本1或版本4。

Version 1: This generates a unique ID based on a network card MAC address and current time. If any of these things is sensitive in any way, don't use this. The advantage of this version is that, while looking at a list of UUIDs generated by machines you trust, you can easily know whether many UUIDs got generated by the same machine, or infer some time relationship between them. Version 4: These are generated from random (or pseudo-random) numbers. If you just need to generate a UUID, this is probably what you want. The advantage of this version is that when you're debugging and looking at a long list of information matched with UUIDs, it's quicker to spot matches.

如果需要从给定的名称生成可重复的uuid，则需要版本3或版本5。如果您正在与其他系统交互，则已经做出了这个选择，您应该检查它们使用的版本和名称空间。

版本3:从命名空间和名称的MD5散列生成唯一ID。如果您正在处理非常严格的资源要求(例如，非常繁忙的Arduino板)，请使用此方法。 版本5:它从名称空间和名称的SHA-1散列生成唯一ID。这是更安全且通常推荐的版本。

由于还没有提到它:如果您希望能够按照创建时间对实体进行排序，而不需要单独的显式时间戳，那么可以使用uuidv1。虽然这不是100%的精确，在许多情况下也不是最好的方法(由于缺乏显式性)，但在某些情况下很方便，例如当您使用Cassanda数据库时。