17370845950

SaveChangesAsync() 必须 await 且在 DbContext 有效期内执行：控制台应用用 async Task Main()，Web 应用注册为 Scoped，避免跨请求复用或提前释放；默认事务保障原子性，显式事务需手动管理；禁止并行调用。

EF Core 的 SaveChangesAsync() 不是“调了就完事”的黑盒方法——它必须在正确的上下文生命周期内被正确等待，否则数据根本不会写入数据库。核心就一条：你得让程序真正等它完成，而不是启动后就不管了。

必须 await，不能只调用

很多人写成这样：

context.Blogs.Add(new Blog { Url = "https://example.com" });
context.SaveChangesAsync(); // 没有 await！

这行代码只是“发起”一个异步任务，主线程立刻往下走，如果此时程序退出（比如控制台应用结束、HTTP 请求快速返回），任务很可能被丢弃，数据就丢了。

✅ 正确写法是：

• 用 await 显式等待完成：await context.SaveChangesAsync();
• 确保整个调用链是 async/await 风格（方法声明加 async Task，调用处加 await）
• 不要混用同步和异步：避免在 async 方法里调 SaveChanges()，也不要在同步方法里直接 .Wait() 或 .Result —— 容易死锁

DbContext 生命周期要管好

SaveChangesAsync() 必须在 DbContext 实例还“活着”时执行。常见坑包括：

• 在 using 块外调用：例如 new 出 context，没用 using 包裹，又没手动 Dispose，可能被 GC 提前回收
• 在 ASP.NET Core 中跨请求复用同一个 DbContext 实例（比如注册为 Singleton）—— DbContext 不是线程安全的，也不支持长生命周期
• 控制台应用中，await SaveChangesAsync() 后直接 Main 方法结束，进程退出 → 数据丢失

✅ 推荐做法：

• 控制台应用：Main 方法设为 async Task Main()，并 await 所有操作
• Web 应用：依赖注入中注册为 Scoped（默认），每个请求一个实例
• 显式释放：用 using var context = new AppDbContext(); 自动处置

事务与批量提交的配合

SaveChangesAsync() 默认自带事务：一次调用中所有增删改操作，要么全成功，要么全回滚（ACID 原子性）。但如果你需要跨多次 SaveChanges 控制一致性，就得手动开事务：

• 用 context.Database.BeginTransaction() 启动显式事务
• 中间可多次 await context.SaveChangesAsync()，都受同一事务保护
• 最后 transaction.Commit() 或异常时 transaction.Rollback()

注意：EF Core 不支持同一 DbContext 上并行执行多个异步操作（比如同时 await 两个 SaveChangesAsync），会抛异常。

常见调试技巧

如果数据没存进去，先检查这几项：

• 实体状态是否为 Added/Modified/Deleted？可用 context.Entry(entity).State 查看
• 有没有漏掉 Add() 或 Update()？光改属性不加跟踪，EF 不知道你要改
• 数据库连接字符串是否正确？表名/列名是否匹配？迁移是否已更新？
• 日志是否开启？在 Program.cs 加 .LogTo(Console.WriteLine) 看 EF 实际执行的 SQL

基本上就这些。不是功能难，而是细节容易忽略。