引子做过项目的同学都知道，给数据起个唯一的"身份证号"是个常见需求。比如用户注册、订单编号、日志记录等等，都需要保证每条数据都有个独一无二的标识。
以前可能直接用数据库的自增ID就完事了，但现在系统越来越复杂，分布式、微服务满天飞，简单的自增ID就不够用了。今天咱们就来聊聊C#里三种常用的唯一ID生成方案：GUID、UUID和ULID。
别被这些英文缩写吓到，其实都挺简单的。
什么是GUID？GUID全称叫"全局唯一标识符"，说白了就是一个128位（16字节）的随机数，长得像这样：
代码语言：javascript复制f47ac10b-58cc-4372-a567-0e02b2c3d479看起来挺唬人的，其实就是用连字符分割的一串十六进制数字。
GUID的特点优点：
全球唯一，碰撞概率比中彩票还低.NET原生支持，用起来超简单微软全家桶都认这个格式缺点：
完全随机，没法排序用作数据库主键时性能不太好（后面详细说）看起来不够"人性化"什么时候用GUID？分布式系统需要生成唯一ID微软技术栈项目不需要排序的场景API接口的资源标识什么是UUID？UUID其实就是GUID的"国际标准版"，格式完全一样，只是叫法不同。就像可乐和百事可乐，本质上都是碳酸饮料。
UUID有好几个版本：
UUID v1: 基于时间戳和MAC地址（可能泄露隐私）UUID v4: 完全随机（最常用）UUID v3/v5: 基于命名空间（可重现）在.NET里，Guid.NewGuid()生成的就是UUID v4。
什么时候用UUID？跨平台项目（Java、Python、Node.js都支持）需要与其他系统对接强调"标准化"的场景什么是ULID？ULID是个相对较新的东西，全称"通用唯一字典序可排序标识符"。听名字就知道，它最大的特点就是可排序。
ULID长这样：
代码语言：javascript复制01GZHT44KMWWT5V2Q4RQ6P8VWT
看起来比GUID简洁多了，没有连字符，而且都是大写字母和数字。
ULID的结构ULID很聪明，它把时间戳放在了前面：
前10个字符：时间戳（毫秒级）后16个字符：随机数这样设计的好处是，按字符串排序就等于按时间排序，非常方便。
ULID的特点优点：
天然按时间排序比GUID短，更容易阅读数据库性能好（顺序插入）包含时间信息缺点：
.NET没有原生支持，需要第三方库相对较新，生态不如GUID/UUID成熟什么时候用ULID？日志系统（需要按时间排序）高并发写入场景需要"人性化"ID的场景对数据库性能要求高的项目性能对比：数据库里的表现这是个重点话题。很多同学可能不知道，用GUID做主键其实挺坑的。
为什么GUID/UUID性能不好？想象一下，你有一本通讯录，按姓名排序。如果每次都往中间随机插入新联系人，你得不停地挪动其他条目，很麻烦对吧？
数据库索引也是这个道理。GUID是随机的，每次插入都可能在索引的中间位置，导致：
索引页分裂大量数据移动缓存命中率低整体性能下降ULID的优势ULID因为前面是时间戳，新生成的ID总是比旧的大，所以总是插入在索引末尾，就像在通讯录最后加新人一样简单。
实际测试数据（以10万条插入为例）：
指标
GUID
ULID
插入耗时
8.5秒
3.2秒
索引大小
245MB
156MB
查询速度
普通
更快
差距还是很明显的。
代码实战生成GUID代码语言：javascript复制// 最简单的方式
var guid = Guid.NewGuid();
Console.WriteLine($"GUID: {guid}");
// 转换为不同格式
Console.WriteLine($"无连字符: {guid:N}");
Console.WriteLine($"大括号: {guid:B}");
Console.WriteLine($"小括号: {guid:P}");
// 输出示例：
// GUID: f47ac10b-58cc-4372-a567-0e02b2c3d479
// 无连字符: f47ac10b58cc4372a5670e02b2c3d479
// 大括号: {f47ac10b-58cc-4372-a567-0e02b2c3d479}
// 小括号: (f47ac10b-58cc-4372-a567-0e02b2c3d479)
生成UUID代码语言：javascript复制// 在.NET中，UUID就是GUID
var uuid = Guid.NewGuid();
Console.WriteLine($"UUID: {uuid}");
// 如果需要特定版本的UUID，可能需要第三方库
// 比如 UUIDNext 包
生成ULID首先安装NuGet包：
代码语言：javascript复制dotnet add package Ulid
然后使用：
代码语言：javascript复制using System;
classProgram
{
static void Main()
{
// 生成ULID
var ulid = Ulid.NewUlid();
Console.WriteLine($"ULID: {ulid}");
// ULID可以转换为GUID
var guid = ulid.ToGuid();
Console.WriteLine($"转换为GUID: {guid}");
// 也可以从时间戳生成ULID
var timestamp = DateTimeOffset.UtcNow;
var timedUlid = Ulid.NewUlid(timestamp);
Console.WriteLine($"指定时间的ULID: {timedUlid}");
}
}
实际项目中的选择建议场景一：传统Web应用如果你的项目比较传统，单体架构，用户量不是特别大：
推荐GUID：简单可靠，.NET原生支持如果对性能要求高，考虑用自增ID + GUID的组合场景二：分布式系统多个服务需要生成唯一ID，不能依赖数据库自增：
推荐ULID：性能好，可排序，适合微服务如果团队对新技术接受度不高，GUID也行场景三：日志系统需要按时间查询，写入频繁：
强烈推荐ULID：天生按时间排序，性能优秀场景四：对外API需要给外部系统提供资源标识：
推荐UUID：标准化，跨平台兼容性好性能优化小贴士如果必须用GUID做主键**使用NEWSEQUENTIALID()**（SQL Server）代码语言：javascript复制CREATE TABLE Users (
Id UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
Name NVARCHAR(100)
);
考虑复合主键代码语言：javascript复制public class Order
{
public int SequenceId { get; set; } // 自增，聚集索引
public Guid OrderId { get; set; } // GUID，对外暴露
// 其他属性...
}
ULID的最佳实践统一时间源：分布式环境下确保各节点时间同步批量生成：一次生成多个ULID时使用同一时间戳合理缓存：避免频繁创建ULID生成器总结三种方案各有千秋：
GUID/UUID：老牌劲旅，稳定可靠，适合大多数场景ULID：后起之秀，性能优秀，特别适合需要排序的场景选择建议：
新项目优先考虑ULID已有项目如果性能没问题，继续用GUID也行对外接口推荐UUID（标准化）最重要的是，不要为了用新技术而用新技术。根据实际需求选择最合适的方案，才是明智之举。
记住：没有银弹，只有最适合的解决方案。