EF Core 6延迟加载异常：访问UserService后才加载Company.Users

1. 确认实体关联配置的正确性 #

先检查Company和User的外键与导航属性配置是否匹配数据库结构：

• 确保User实体有正确的外键字段（如CompanyId），且在DbContext的OnModelCreating中明确关联关系：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<User>()
        .HasOne(u => u.Company)
        .WithMany(c => c.Users)
        .HasForeignKey(u => u.CompanyId);
}

• 核对数据库中Users表的CompanyId值，确认测试数据的外键确实指向目标公司的主键，没有空值或错误值。

2. 验证Include是否被正确执行 #

检查GetCompanyById的实现，确保Include没有被后续操作覆盖：

public async Task<Company> GetCompanyById(int id)
{
    using var context = _dbContextFactory.CreateDbContext();
    return await context.Companies
        .Include(c => c.Users)
        .FirstOrDefaultAsync(c => c.Id == id);
}

• 开启EF Core日志，查看生成的SQL语句是否包含JOIN Users的片段，确认关联查询是否真正执行。如果SQL里没有JOIN，说明Include被意外忽略（比如后续调用了Select等操作覆盖了查询）。

3. 排查DbContext的生命周期问题 #

你用了AddDbContextFactory，理论上每次CreateDbContext()都会生成新上下文，但如果服务中存在上下文复用的情况（比如错误注入了单例DbContext而非通过工厂创建），就会出现跟踪状态干扰：

• 先访问用户列表时，上下文会跟踪User实体；后续查询公司时，如果复用了同一个上下文，EF会自动将已跟踪的User关联到Company的导航属性，这就是“先查用户再查公司能加载数据”的原因——本质是依赖了旧上下文的跟踪实体，而非当前查询的Include结果。
• 确保所有数据访问操作都通过_dbContextFactory.CreateDbContext()创建新上下文，且使用using块确保上下文及时释放。

4. 检查是否存在查询缓存干扰 #

EF Core会缓存查询计划，如果之前的查询没有包含Include，可能导致缓存的查询未执行关联。可以重启应用后再测试，排除缓存影响。

5. 补充：延迟加载的影响（优先级较低） #

虽然你用了Include，但如果Company.Users未标记为virtual且延迟加载未启用，不会触发延迟加载，但这不是Include失效的原因，不过可以作为补充检查项。

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