GUID是“全局唯一ID”。也称为UUID (通用唯一ID)。
它基本上是一个128位的数字，其生成方式(参见RFC4112 http://www.ietf.org/rfc/rfc4122.txt)使得几乎不可能生成重复项。这样，我就可以生成GUID，而不必让一些第三方组织提供给我，以确保它们是唯一的。
GUID的一个广泛使用是作为Windows上的COM实体(类、类型库、接口等)的标识符。使用GUID，开发人员可以构建他们的COM组件，而无需去Microsoft获取唯一标识符。尽管标识COM实体是GUID的主要用途，但它们也用于许多需要唯一标识符的事情。一些开发人员将为数据库记录生成GUID，以便为它们提供一个ID，即使它们在许多不同的数据库中必须是唯一的，也可以使用。
通常，您可以将GUID视为任何人都可以在任何时候生成的序列号，并且他们将知道该序列号将是唯一的。
获取唯一标识符的其他方法包括获取域名。为了保证域名的唯一性，您必须从某个组织(最终由ICANN管理)获取。
因为GUID可能很笨拙(从人类可读的角度来看，它们是一个十六进制数字字符串，通常分组如下: aaaaaaaa-bbbb-cccc-dddd-ffffffffffff)，一些在不同组织中需要唯一名称的命名空间使用另一种方案(通常基于Internet域名)。
因此，按照惯例，Java包的名称空间以组织的域名(颠倒过来)开头，后跟以特定于组织的方式确定的名称。例如，Java包可以命名为：
代码语言：javascript运行复制com.example.jpackage这意味着处理名称冲突成为每个组织的责任。
XML名称空间也是以类似的方式唯一的-按照惯例，创建XML名称空间的人应该将其“置于”他们控制下的注册域名之下。例如：
代码语言：javascript运行复制xmlns="http://www.w3.org/1999/xhtml"管理唯一ID的另一种方式是以太网MAC地址。制造以太网卡的公司必须获得IEEE分配给它们的地址块(我认为是IEEE)。在这种情况下，该方案工作得很好，即使制造商搞砸了，并发行了具有重复MAC地址的卡，只要这些卡不在同一子网上，事情仍然可以正常工作，因为在子网之外，只有IP地址用于路由数据包。尽管MAC地址的其他一些用途可能会受到影响，但生成GUID的算法之一使用MAC地址作为一个参数。这种GUID生成方法不再被广泛使用，因为它被认为是对隐私的威胁。
微软为Windows9x中的“VxD”驱动程序提供的ID就是一个不太管用的唯一标识符方案的一个例子。第三方VxD驱动程序的开发人员应该要求微软提供一组ID，用于第三方编写的任何驱动程序。这样，微软就可以确保不会有重复的ID。不幸的是，许多驱动程序编写人员从不费心，只是简单地使用他们用作起点的示例VxD中的任何ID。我不确定这造成了多大的麻烦-我不认为VxD ID唯一性是绝对必要的，但它可能会影响一些API中的某些功能。