EF Core调用SaveChangesAsync后DepartmentId偶现被设为NULL的问题求助

针对你遇到的相同输入下LeaveRequest实体DepartmentId属性时而正常更新、时而被设为NULL的问题，结合你的代码配置和环境，给出以下具体排查方向和验证步骤：

1. 优先排查AutoMapper映射对导航属性的影响 #

你的更新逻辑依赖AutoMapper将输入实体映射到数据库读取的实体上，导航属性Department的意外覆盖是最可能的诱因：

• 检查AutoMapper Profile配置，确认是否未忽略Department导航属性。如果输入实体leaveRequestForDb的Department为null，而映射规则未忽略该属性，会将数据库实体leaveRequestFromDb的Department覆盖为null。
• EF Core中，导航属性与外键属性（DepartmentId）是联动的：当导航属性被设为null时，EF会自动将对应的外键属性设为null，即使你手动设置了外键值。
• 验证步骤：
  在映射后添加日志，打印leaveRequestFromDb.Department和leaveRequestFromDb.DepartmentId的值；同时修改AutoMapper配置，显式忽略导航属性：

  CreateMap<LeaveRequest, LeaveRequest>()
      .ForMember(dest => dest.Department, opt => opt.Ignore());
  

  测试是否还会出现DepartmentId被设为NULL的情况。

2. 检查EF Core变更跟踪与上下文生命周期 #

• 上下文复用问题：API项目使用.NET 7，数据项目为EF Core 3.1，若DbContext被注册为Singleton而非Scoped，会导致多请求复用同一上下文，变更跟踪状态被干扰，出现间歇性异常。
  • 验证步骤：确认DbContext的注册方式为Scoped：

    services.AddDbContext<YourDbContext>(options => 
        options.UseSqlServer(connectionString), ServiceLifetime.Scoped);
    

• 变更跟踪调试：在SaveChangesAsync前输出EF Core变更跟踪的详细信息，对比成功与失败请求的差异：

  var debugLog = _dbContext.ChangeTracker.DebugView.LongView;
  // 将debugLog写入日志或控制台
  

  重点查看LeaveRequest实体的DepartmentId属性是否被标记为"Modified"，以及导航属性Department的跟踪状态。

3. 排查数据库触发器逻辑 #

虽然审计记录显示仅一次更新，但触发器内部可能存在条件逻辑，在特定场景下修改DepartmentId：

• 查看Leave_Request表的触发器代码，检查是否存在对DepartmentId字段的赋值操作，尤其是依赖其他表数据或动态条件的逻辑。
• 测试禁用触发器后，问题是否消失，以此排除触发器的影响。

4. 验证EF Core复合外键配置 #

你的模型中LeaveRequest与Department的外键是复合键(CompanyCode, DepartmentId)，即使数据库外键被禁用，EF Core仍会基于模型配置处理关系：

• 确认更新时CompanyCode未被意外修改：如果CompanyCode变更，而新的(CompanyCode, DepartmentId)组合不存在，EF Core可能将DepartmentId设为null。
• 显式强制EF Core更新DepartmentId：在映射后添加代码，手动标记属性为已修改：

  _dbContext.Entry(leaveRequestFromDb).Property(x => x.DepartmentId).IsModified = true;
  

5. 检查数据类型与映射一致性 #

• 确认数据库中Leave_Request表的DepartmentId字段类型为int且允许为NULL，与实体定义的int?一致。
• 检查Department实体的DepartmentId配置：ValueGeneratedOnAdd仅针对Department自身的主键生成，不影响LeaveRequest的外键，但需确保无其他冲突配置。

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