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
基本上就这些。不是功能难，而是细节容易忽略。
