在事务中执行多个Identity操作的可行性及上下文一致性疑问

你提到的事务用法是可行的，核心假设基本正确，以下针对你的疑问逐一说明：

疑问1：Identity每个操作后调用SaveChanges，回滚是否有效？ #

当手动通过_context.Database.BeginTransactionAsync()开启EF Core事务后，所有通过该DbContext执行的SaveChanges（包括UserManager内部调用的）都会被纳入这个事务边界内。

虽然UserManager的每个操作（比如创建用户、添加角色等）都会立即调用SaveChanges，但这些变更只是暂存在事务的上下文缓存中，并不会直接提交到数据库。只有当你主动调用transaction.CommitAsync()时，所有累积的变更才会一次性提交；如果执行进入catch块，事务在释放时会自动回滚所有通过该上下文执行的变更，包括UserManager操作产生的所有数据修改。

疑问2：_context是否与_userManager内部使用的上下文为同一个？ #

在默认的ASP.NET Core依赖注入配置中，DbContext被注册为作用域服务（Scoped），即同一个HTTP请求生命周期内，所有注入的DbContext实例都是同一个。

UserManager内部依赖的默认UserStore实现会通过依赖注入获取该作用域内的DbContext，因此你的代码中注入的_context和_userManager内部使用的上下文确实是同一个实例——这也是事务能覆盖所有Identity操作的核心前提。

额外注意事项 #

• 避免在事务流程中手动创建新的DbContext实例（比如new AppDbContext()），这类独立的上下文操作不会被纳入当前事务，无法回滚。
• 如果项目中自定义了UserStore或修改了DbContext的注册方式（比如改为瞬时服务），需要验证上下文实例的一致性，否则事务可能无法覆盖所有操作。

更新说明 #

目前官方文档确实缺乏针对Identity事务场景的明确说明，依赖内部实现细节确实存在风险。你提到的文档请求情况属实，若有相同困扰可关注相关仓库的后续进展。

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