迁移至SQLite后，EF Core中GUID类型过滤器返回null的原因？

问题原因 #

SQLite与SQL Server对GUID的存储处理逻辑存在差异：

• SQL Server默认以二进制格式存储GUID，字节顺序为小端序
• SQLite默认将GUID转为字符串存储，若用二进制存储，字节顺序也可能和SQL Server不一致
  当EF Core生成的SQL查询中，GUID的序列化格式与数据库存储格式不匹配时，就会出现过滤无结果的情况。而AsEnumerable()是把全量数据拉到本地用.NET原生GUID比较，所以能匹配成功，但大数据场景下性能极差。

解决办法 #

1. 统一GUID的存储与转换格式 #

用EF Core的Fluent API配置实体属性的GUID转换规则，确保查询匹配逻辑和存储格式一致：

方案A：转为无分隔符字符串存储（兼容性好）

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<CompanyBranch>()
        .Property(b => b.CompanyId)
        .HasConversion(
            guid => guid.ToString("N"), // 存储时转成无连字符的字符串（如"12345678123456781234567812345678"）
            str => Guid.Parse(str)); // 查询时转回GUID
}

方案B：用二进制存储（性能更优）

如果追求更好的查询性能，可配置为二进制存储，同时统一字节顺序：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<CompanyBranch>()
        .Property(b => b.CompanyId)
        .HasConversion<byte[]>(
            guid => guid.ToByteArray(),
            bytes => new Guid(bytes));
}

注意：若数据是从SQL Server迁移而来，需确保迁移时将SQL Server的二进制GUID转换成标准字节顺序（SQL Server存储的GUID字节顺序与.NET默认不同），否则仍会匹配失败。

2. 检查数据库现有数据格式 #

如果是从SQL Server迁移的数据，先确认CompanyId字段的存储格式：

• 若为字符串，检查是否是无分隔符格式，与配置的转换规则是否一致
• 若为二进制，检查字节顺序是否与.NET的Guid.ToByteArray()输出一致，不一致则需要批量转换数据格式

3. 验证生成的SQL语句 #

通过ToQueryString()查看EF Core生成的SQL，确认参数传递格式是否正确：

var query = _apiDbContext.CompanyBranches.Where(a => a.CompanyId == companyId);
Console.WriteLine(query.ToQueryString());

比如生成的SQL如果用字符串参数匹配数据库中的二进制GUID，必然查不到结果，此时需要调整转换配置。

4. 升级SQLite EF Core包 #

可以尝试升级到同主版本的最新补丁包（比如8.0.x的最新版），部分小版本更新会修复GUID相关的兼容性bug。

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