开发C#怎么生成球唯一标识 C#如何创建GUID字符串基础最佳践|Duuu笔记
深入理解前端原理，本文探讨
绝大多数场景下应直接使用 Guid.NewGuid() 生成 GUID，它调用系统安全随机数生成器确保唯一性；需字符串时用 ToString() 或 ToString("N")，避免手动拼接、哈希码作 ID 或误判 Guid.Empty。
用
Guid.NewGuid()
生成新 GUID 最稳妥
绝大多数场景下，直接调用
guid.newguid()
就是正确答案。它由 .net 运行时调用系统底层随机数生成器（windows 上是
cryptgenrandom
或 bcrypt，linux/macos 是
/dev/urandom
），保证统计学意义上的唯一性，且不依赖网络、时间戳或硬件 id。
常见错误是手动拼接时间戳 + 进程号 + 随机数——这既不安全也不必要，还容易因时钟回拨或并发导致重复。
Guid.NewGuid()
返回的是
Guid
类型，不是字符串；需要转成字符串再用，比如
guid.ToString()
默认
ToString()
输出带短横线的 32 位十六进制格式（如
"a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"
）
如果只要纯数字字母（无短横线），用
guid.ToString("N")
；要大写就加
.ToUpper()
什么时候不能用
Guid.NewGuid()
？
极少数情况：你需要可预测、可重现的 GUID（比如测试中固定值），或者必须基于某个输入（如字符串、字节数组）生成确定性 GUID。
这时不能硬套
NewGuid()
，得用
Guid.Parse()
或
Guid.TryParse()
解析已有字符串，或用
Guid.CreateFromBytes()
（.NET 7+）构造。
从字符串解析失败会抛
FormatException
，务必用
Guid.TryParse()
做前置校验
Guid.CreateFromBytes()
输入必须是 16 字节；用
Encoding.UTF8.GetBytes()
转字符串会超长，得先哈希（如
SHA256.HashData()
）再截取前 16 字节
别用
Guid.NewGuid().ToString().GetHashCode()
当 ID——哈希码不是全局唯一，不同 GUID 可能哈希冲突
Guid.Empty
不是“空字符串”，而是全零 GUID
新手常误以为
Guid.Empty
表示“未初始化”或“可忽略”，其实它是合法的 GUID 值：
"00000000-0000-0000-0000-000000000000"
。数据库里存它、API 传它，都算有效值，只是业务上通常约定它代表“未设置”。
独响
一个轻笔记+角色扮演的app
下载
判断是否为默认值，用
guid == Guid.Empty
，不要用
guid.ToString() == ""
（会报错）或
string.IsNullOrEmpty(guid.ToString())
（永远 false）
Entity Framework 中若字段允许 null，建议用
Guid?
（可空类型），比用
Guid.Empty
更语义清晰
JSON 序列化时，默认把
Guid.Empty
输出为
"00000000-0000-0000-0000-000000000000"
，前端可能误判为有效 ID
性能和序列化要注意的小细节
GUID 字符串长度固定（36 字符含短横线），但生成和格式化有开销。高频创建（比如每秒万级）时，
Guid.NewGuid()
本身很快，但
ToString()
是主要瓶颈。
避免在循环里反复调用
guid.ToString("D")
（D 是默认格式）；如果格式固定，提前缓存格式化结果或用
Span
手动拼接（.NET 6+）
数据库索引对 GUID 不友好——无序插入导致页分裂；若主键用 GUID，考虑用
NEWSEQUENTIALID()
（SQL Server）或
uuid_generate_v1mc()
（PostgreSQL）替代
gRPC 或高性能 API 中，传输二进制
Guid.ToByteArray()
比字符串省 75% 字节，但需两端协议一致
真正麻烦的不是怎么生成，而是后续怎么用：存进数据库时要不要索引、传给前端要不要脱敏、日志里要不要截断显示……这些地方一不留神，
Guid
就从“唯一标识”变成“排查黑洞”。
