EF Core使用FirstOrDefaultAsync查询GUID主键实体返回null问题

针对你遇到的问题——使用FirstOrDefaultAsync()通过GUID主键查询Claim实体返回null，但ToListAsync()全量查询后内存过滤能找到该实体，且添加重复实体时触发唯一约束——核心原因大概率是SQLite与EF Core对GUID的存储/查询格式不匹配，或EF Core查询生成逻辑在特定场景下的异常。以下是具体排查和解决步骤：

1. 检查EF Core生成的SQL语句 #

首先确认FirstOrDefaultAsync()生成的SQL是否正确。在DbContext的OnConfiguring方法中添加日志输出，查看实际执行的SQL：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseSqlite("你的连接字符串")
                  .LogTo(Console.WriteLine, Microsoft.Extensions.Logging.LogLevel.Information);
}

运行代码后，观察查询Claim的SQL语句，重点看WHERE Id = ?中的参数格式是否与数据库中存储的GUID格式一致。如果数据库中GUID以字符串形式存储，但EF Core生成的SQL用了二进制参数，就会导致查询匹配失败。

2. 强制指定GUID的存储格式 #

SQLite本身没有原生GUID类型，EF Core默认会将GUID以二进制（BLOB）格式存储，但部分场景下可能出现查询不匹配的问题。可以强制将GUID存储为字符串（TEXT类型）：

方式一：全局配置 #

在UseSqlite时添加全局GUID格式配置：

optionsBuilder.UseSqlite("你的连接字符串", options =>
{
    options.UseGuidAsBinary(false); // 将GUID存储为TEXT类型
});

方式二：实体属性单独配置 #

在DbContext的OnModelCreating中单独配置Claim的Id属性：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Claim>()
        .Property(c => c.Id)
        .HasColumnType("TEXT");
}

3. 直接查询本地上下文缓存 #

如果该实体已经被上下文追踪（比如之前添加但未SaveChanges，或已从数据库加载到本地），可以直接查询Local属性获取本地实体：

var claim = context.Claims.Local.FirstOrDefault(x => x.Id == claimId);
// 如果本地没有，再查询数据库
if (claim == null)
{
    claim = await context.Claims.FirstOrDefaultAsync(x => x.Id == claimId);
}

4. 排查EF Core版本问题 #

EF Core 9.0是较新的版本，可能存在查询优化相关的bug。可以尝试降级到稳定的EF Core 8.0.x版本，验证问题是否消失。

5. 手动编写SQL查询 #

如果上述方法都无效，可以用原生SQL直接查询，绕开EF Core的LINQ查询生成逻辑：

var claim = await context.Claims
    .FromSqlRaw("SELECT * FROM Claims WHERE Id = {0}", claimId.ToString())
    .FirstOrDefaultAsync();

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