EF Core保存点是在显式事务中设置的中途检查点，支持局部回滚而不终止事务，需用CreateSavepoint和RollbackToSavepoint操作，名称唯一且不可跨连接，使用后需手动清理ChangeTracker状态。
EF Core 的保存点（Savepoint）是在一个事务内部设置的“中途检查点”，它允许你在不放弃整个事务的前提下，回滚到某个中间状态。这特别适合需要局部失败容忍的复杂业务流程，比如批量导入中部分数据校验失败、多步骤订单创建中某环节出错等场景。
保存点的基本用法
保存点必须在显式事务中使用，不能在 SaveChanges 的隐式事务里生效。核心方法就两个：CreateSavepoint(string name) 和 RollbackToSavepoint(string name)。
- 调用 CreateSavepoint 会记录当前事务的执行状态，后续操作若失败，可精准回退至此点
- RollbackToSavepoint 不会终止事务，回滚后仍可继续执行其他操作并最终 Commit
- 保存点名称必须唯一，重复创建同名保存点会覆盖前一个
典型使用示例
假设你要插入一批博客，但其中一条因 URL 过长触发数据库约束而失败，你希望保留前面成功的记录：
using var transaction = context.Database.BeginTransaction();
try
{
context.Blogs.Add(new Blog { Url = "https://a.com" });
context.SaveChanges();
transaction.CreateSavepoint("AfterFirstBlog");
context.Blogs.Add(new Blog { Url = "https://b.com" });
context.Blogs.Add(new Blog { Url = "https://very-long-url-that-will-fail..." }); // 触发异常
context.SaveChanges();
transaction.Commit();
}
catch
{
transaction.RollbackToSavepoint("AfterFirstBlog");
transaction.Commit(); // 此时只有第一条 blog 被提交
}
保存点与嵌套事务的区别
EF Core 不支持真正的嵌套事务（SQL Server 的 SAVE TRANSACTION 是模拟的），但保存点提供了类似效果：
- 嵌套事务在多数数据库中只是语法糖，底层仍是单事务；EF Core 的保存点也是同理
- 不能对保存点做 Commit，只能 Rollback 到它；而嵌套事务理论上可单独提交（实际不可靠）
- 保存点开销极小，比开启新事务更轻量，适合高频细粒度控制
注意事项和常见坑
保存点虽灵活，但容易误用：
- 必须在 BeginTransaction() 后调用，否则抛出 InvalidOperationException
- RollbackToSavepoint 后，被回滚的操作所涉及的实体状态仍留在 ChangeTracker 中，需手动处理（如 Remove 或 Reset）避免下次 SaveChanges 再次尝试插入已失败的数据
- 保存点不跨连接，如果事务中切换了数据库连接（如读写分离），保存点可能失效
- SQLite 对保存点支持较弱，建议在 SQL Server 或 PostgreSQL 等成熟关系库中使用
基本上就这些。用好保存点，能让事务逻辑更健壮，既避免全盘回滚的浪费，又守住数据一致性底线。