ASP.NET Core Identity：ApplicationDbContext与UserManager上下文及操作差异问询

好问题！咱们一步步拆解你遇到的两个核心疑问：

一、注入的ApplicationDbContext与UserManager使用的是同一实例吗？ #

答案是：在默认配置下，同一个作用域内（比如同一个请求生命周期），二者会共享同一个DbContext实例。

原因在于：

• ASP.NET Core中，ApplicationDbContext默认是以Scoped生命周期注册的（通过services.AddDbContext<ApplicationDbContext>(...)），意味着每个作用域会创建一个实例。
• UserManager<ApplicationUser>同样是Scoped生命周期（通过AddIdentity或AddDefaultIdentity注册），它内部依赖的UserStore也会从同一个作用域中获取ApplicationDbContext实例。

所以只要你的Initialize方法是在同一个作用域中执行的，你注入的context和UserManager内部使用的上下文就是同一个实例。

二、为什么CreateAsync无需手动SaveChanges，而UpdateAsync需要？ #

这是因为UserManager的默认实现中，CreateAsync和UpdateAsync的逻辑不一样：

1. CreateAsync的内部逻辑 #

当你调用userManager.CreateAsync(adminTeacherUser, "password").Wait()时：

• UserManager会调用底层UserStore的CreateAsync方法
• 该方法会先将用户实体添加到DbContext（context.Add(user)）
• 关键：默认实现会自动调用context.SaveChangesAsync()，所以数据会立即持久化到数据库，不需要你手动调用保存方法。

2. UpdateAsync的内部逻辑 #

而当你修改实体后调用userManager.UpdateAsync(adminTeacherUser)时：

• UserManager调用UserStore的UpdateAsync方法
• 该方法仅会将实体标记为Modified状态（context.Update(user)）
• 默认实现不会自动调用SaveChangesAsync()，所以修改只会停留在内存的DbContext中，直到你手动调用context.SaveChanges()或context.SaveChangesAsync()，才会同步到数据库。

小提示 #

如果你想让UpdateAsync自动完成持久化，可以有两种选择：

• 在调用UpdateAsync后，手动调用await context.SaveChangesAsync()（注意要异步等待，避免同步阻塞）
• 自定义UserStore，重写UpdateAsync方法，在方法末尾添加await Context.SaveChangesAsync(cancellationToken)

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