Guid.NewGuid() 是生成最简 GUID 字符串的首选方案，线程安全、跨版本一致，应避免手动截断或误用 Guid.Empty。
用 guid.newguid() 生成最简 guid 字符串
绝大多数场景下，guid.newguid() 就是你要的答案。它不依赖外部状态、不需配置、线程安全，且在 .net 所有主流版本（.net framework 2.0+ / .net core 1.0+ / .net 5+）里行为一致。
常见错误是手动拼接或截断 GUID——比如取前 8 位当 ID，这直接破坏唯一性保证；还有人误以为 Guid.Empty 可用作默认值再替换，结果漏掉初始化逻辑，导致大量 00000000-0000-0000-0000-000000000000 冒充 ID。
-
Guid.NewGuid().ToString()→"a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"（带连字符，32 字符 + 4 连字符） -
Guid.NewGuid().ToString("N")→"a1b2c3d4e5f67890g1h2i3j4k5l6m7n8"（纯数字字母，32 字符） -
Guid.NewGuid().ToString("D")同默认ToString()，显式写更清晰 - 别用
ToString("B")或"P"——引号、花括号这些额外符号只在调试或注册表场景才需要
数据库主键场景：SQL Server 的 NEWID() vs C# 的 Guid.NewGuid()
如果你的表主键是 UNIQUEIDENTIFIER，且希望 ID 在插入时由数据库生成，就该用 NEWID()（或更优的 NEWSEQUENTIALID()），而不是在 C# 层生成后传入。否则会丢失数据库端的可控性，比如无法做批量插入预生成、无法审计来源、还可能因网络失败导致 ID 已生成但数据未落库。
反过来，如果业务要求“ID 必须在创建对象实例时确定”（如事件溯源、离线缓存、分布式事务前置 ID），就必须在 C# 层调用 Guid.NewGuid()，并确保 ORM（如 EF Core）正确映射为 ValueGenerated.Never。
- EF Core 中禁用自动生成：
modelBuilder.Entity<order>().Property(e => e.Id).ValueGeneratedNever();</order> - SQL Server 中设默认值为
NEWSEQUENTIALID()，比NEWID()更利于索引性能（减少页分裂） - PostgreSQL 没原生 GUID 类型，常用
UUID类型 +gen_random_uuid()，此时 C# 端仍用Guid.NewGuid()，但需 NpgSql 支持转换
性能敏感场景：避免重复 ToString() 和大小写混用
GUID 字符串本身不参与计算，但频繁转字符串、尤其在日志或缓存 Key 构造中，会触发内存分配和 GC 压力。更隐蔽的问题是大小写——Guid 解析不区分大小写，但字符串比较（如字典查找、HTTP Header）是区分的。同一 GUID 出现 "ABC..." 和 "abc..." 会被当成两个不同 Key。
- 高频生成时，直接保留
Guid类型变量，仅在必要输出时调用ToString("N") - 若用于缓存 Key，统一转小写：
guid.ToString("N").ToLowerInvariant()（ToLower()有文化敏感风险） - 不要用
string.Format("{0:N}", guid)——比直接ToString("N")多一次装箱和格式解析开销 - .NET 6+ 可用
guid.TryFormat(span, out int charsWritten, "N")避免堆分配，但仅限极苛刻场景
替代方案：什么时候不该用 GUID？
GUID 不是银弹。如果你的系统单机部署、QPS 很低、ID 仅用于内部标识，而你又在意存储空间（16 字节 vs 自增 int 的 4 字节）、索引效率（随机 GUID 导致 B+ 树频繁分裂）、或可读性（日志里全是 e2f8...a1b2），那就要考虑其他方案。
- 短 ID：用
IdGen或Twitter Snowflake的 C# 实现（如InstagramSnowflake），生成 64 位有序 long，再 Base62 编码成 6–8 字符字符串 - 时间戳前缀 + 随机后缀：如
DateTimeOffset.UtcNow.ToString("yyMMddHHmmss") + Random.Shared.Next(1000, 9999)，适合非强唯一、有时间序需求的场景 - 数据库自增 ID + 应用层加盐哈希：仅限对安全性要求不高、且能容忍偶尔碰撞的后台任务 ID
- 别自己实现“基于 MAC 地址 + 时间 + 计数器”的 GUID——
Guid.NewGuid()底层已优化多年，自行实现大概率更慢、更不唯一
真正难的是判断“是否真需要全局唯一”。很多所谓“分布式”系统其实只是多副本，主从同步即可，根本不需要跨集群 ID 一致。这时候 GUID 只是凭感觉加的重量。
