使用UserManager的UpdateAsync方法在EntityFrameworkCore中抛出InvalidOperationException异常

我之前也碰到过类似的问题，这种冲突通常和EF Core的实体跟踪机制以及Identity的UserManager内部工作逻辑有关，给你分析几个可能的原因和对应的解决办法：

核心原因 #

EF Core的DbContext会跟踪所有从它加载的实体，同一个上下文中绝对不能存在两个主键相同的被跟踪实体。而UserManager在执行UpdateAsync时，内部可能已经通过查询（比如验证用户状态、获取当前数据等操作）把这个UserProfile实例加载到了上下文里，这时候如果你传入的是另一个未被当前上下文跟踪的、主键相同的UserProfile对象，就会触发这个异常。

解决方案 #

1. 优先使用UserManager获取的实例进行更新 #

这是最稳妥的方式，先通过UserManager的方法（比如FindByIdAsync）获取当前上下文已经跟踪的用户实例，再修改它的属性后调用UpdateAsync：

// 假设你有要更新的用户ID和新的属性值
var existingUser = await _userManager.FindByIdAsync(targetUserId);
if (existingUser != null)
{
    // 在这里更新用户属性，比如：
    existingUser.Email = newEmail;
    existingUser.UserName = newUserName;
    
    var updateResult = await _userManager.UpdateAsync(existingUser);
    // 处理更新结果
}

这样用的是DbContext已经在跟踪的实例，完全避免了重复跟踪的问题。

2. 检查是否有其他操作提前加载了用户实例 #

有时候你可能没意识到，请求过程中其他地方已经加载过这个用户了——比如认证中间件在请求开始时，就已经把当前登录用户加载到DbContext中跟踪了；或者其他服务/方法在更新前查询过该用户。这种情况下，你自己创建或从外部传入的UserProfile实例就会和已跟踪的实例冲突，这时候用上面的方法获取已跟踪实例更新就可以解决。

3. 确认DbContext的生命周期配置 #

确保你的AvgContext是按Scoped生命周期注册的（这是默认配置），如果不小心注册成了Singleton，会导致多个请求共享同一个上下文，很容易出现这种跟踪冲突问题。检查Startup里的DbContext注册代码：

services.AddDbContext<AvgContext>(options => 
    options.UseSqlServer(Configuration.GetConnectionString("YourConnectionString")));

（默认AddDbContext就是Scoped，除非你手动指定了ServiceLifetime.Singleton）

4. 手动处理实体跟踪状态（不推荐，仅特殊场景用） #

如果必须使用自己的UserProfile实例，可以先把它附加到DbContext，并处理跟踪状态，但这种方式需要注意冲突处理，不如第一种方法安全：

var userToUpdate = // 你的UserProfile实例
var entry = _context.Attach(userToUpdate);
entry.State = EntityState.Modified;
// 或者如果只更新部分属性，可以手动标记属性为修改
// entry.Property(u => u.Email).IsModified = true;

await _context.SaveChangesAsync();

不过这种方式会绕开UserManager内部的一些Identity逻辑（比如密码验证、角色关联等），所以除非特殊情况，不建议这么做。

备注：内容来源于stack exchange，提问作者Marth