绝大多数场景下应直接使用 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 传它，都算有效值，只是业务上通常约定它代表“未设置”。
- 判断是否为默认值，用
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<char></char>手动拼接（.NET 6+） - 数据库索引对 GUID 不友好——无序插入导致页分裂；若主键用 GUID，考虑用
NEWSEQUENTIALID()（SQL Server）或uuid_generate_v1mc()（PostgreSQL）替代 - gRPC 或高性能 API 中，传输二进制
Guid.ToByteArray()比字符串省 75% 字节，但需两端协议一致
真正麻烦的不是怎么生成，而是后续怎么用：存进数据库时要不要索引、传给前端要不要脱敏、日志里要不要截断显示……这些地方一不留神，Guid 就从“唯一标识”变成“排查黑洞”。
