这确实是.NET Guid和传统大端UUID存储之间的常见迁移痛点，我之前在项目里也踩过这个坑，分享几个优雅的解决方案，帮你避开临时方案的繁琐：

核心问题背景 #

.NET的Guid结构体遵循RFC 4122规范，内部采用混合端序存储：前4字节（int32）、中间2字节（int16）、再2字节（int16）是小端序，最后8字节是大端序。而你的旧系统MySQL用binary(16)存储的是纯大端序的UUID字节数组，直接用.NET原生Guid处理会导致字符串表示完全不一致。

解决方案1：自定义端序转换扩展方法 #

最直接的方式是写一组扩展方法，在Guid和大端字节数组之间互相转换，手动调整端序：

public static class GuidEndianExtensions
{
    // 将.NET Guid转换为大端字节数组（适配MySQL binary(16)存储）
    public static byte[] ToBigEndianByteArray(this Guid guid)
    {
        var bytes = guid.ToByteArray();
        
        // 反转小端部分的字节序：前4字节、中间2字节、再2字节
        Array.Reverse(bytes, 0, 4);
        Array.Reverse(bytes, 4, 2);
        Array.Reverse(bytes, 6, 2);
        
        // 最后8字节保持大端，无需调整
        return bytes;
    }

    // 从MySQL的大端字节数组还原为.NET Guid
    public static Guid FromBigEndianByteArray(this byte[] bigEndianBytes)
    {
        if (bigEndianBytes.Length != 16)
            throw new ArgumentException("字节数组长度必须为16", nameof(bigEndianBytes));
            
        var bytes = (byte[])bigEndianBytes.Clone();
        
        // 反向转换端序，还原为.NET Guid的混合端格式
        Array.Reverse(bytes, 0, 4);
        Array.Reverse(bytes, 4, 2);
        Array.Reverse(bytes, 6, 2);
        
        return new Guid(bytes);
    }

    // 直接生成符合大端格式的Guid（转换后字符串与旧API一致）
    public static Guid GenerateBigEndianGuid()
    {
        return Guid.NewGuid().ToBigEndianByteArray().FromBigEndianByteArray();
    }
}

使用示例：

// 生成与旧API一致的UUID字符串
var bigEndianGuid = GuidEndianExtensions.GenerateBigEndianGuid();
string uuidString = bigEndianGuid.ToString(); // 这个字符串和旧API输出完全匹配

// 从数据库读取binary(16)字段转换为Guid
byte[] dbBytes = await _dbContext.Entities.Select(e => e.IdBytes).FirstAsync();
Guid entityId = dbBytes.FromBigEndianByteArray();

解决方案2：EF Core值转换器（自动处理数据库读写） #

如果用EF Core操作数据库，可以配置值转换器，让EF在读写binary(16)字段时自动完成端序转换，业务代码完全不用感知：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 定义Guid与大端字节数组的转换器
    var bigEndianConverter = new ValueConverter<Guid, byte[]>(
        guid => guid.ToBigEndianByteArray(), // 写入数据库时转大端
        bytes => bytes.FromBigEndianByteArray() // 读取时转.NET Guid
    );

    // 为实体的Guid主键配置转换器
    modelBuilder.Entity<YourEntity>()
        .Property(e => e.Id)
        .HasColumnType("binary(16)")
        .HasConversion(bigEndianConverter);
}

这样在业务代码中直接使用Guid类型即可，EF会自动处理端序转换，完全透明。

解决方案3：Web API序列化自定义（确保输出字符串一致） #

如果你的API需要返回UUID字符串，确保序列化后的结果和旧API一致，可以自定义Json转换器（以System.Text.Json为例）：

public class BigEndianGuidJsonConverter : JsonConverter<Guid>
{
    public override Guid Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        var uuidString = reader.GetString();
        return Guid.Parse(uuidString).ToBigEndianByteArray().FromBigEndianByteArray();
    }

    public override void Write(Utf8JsonWriter writer, Guid value, JsonSerializerOptions options)
    {
        // 先转换为大端格式的Guid，再输出字符串
        var bigEndianGuid = value.ToBigEndianByteArray().FromBigEndianByteArray();
        writer.WriteStringValue(bigEndianGuid.ToString());
    }
}

然后在Startup/Program.cs中注册转换器：

builder.Services.AddControllers()
    .AddJsonOptions(options =>
    {
        options.JsonSerializerOptions.Converters.Add(new BigEndianGuidJsonConverter());
    });

这样API返回的UUID字符串就会和旧系统完全一致了。

这些方案都能优雅解决端序不一致的问题，避免临时方案的维护成本。如果你的场景有特殊需求，比如需要和第三方库兼容，再考虑调整实现细节。

内容的提问来源于stack exchange，提问作者Thomas Horrobin