EF Core中的SaveChanges是DbContext最核心的方法之一，负责将上下文里所有被跟踪实体的变更同步到数据库。理解它的工作机制，能让你在开发数据访问层时少踩很多坑。
SaveChanges的基本作用
当使用EF Core的DbContext时，无论是新增、修改还是删除实体，这些操作最初都只发生在内存中的变更跟踪器里。只有显式调用SaveChanges或SaveChangesAsync，EF Core才会生成对应的SQL语句并执行，把数据真正写入库表。
一个简单的保存示例
下面代码演示了添加一条记录并保存的过程：
using (var context = new AppDbContext())
{
var user = new User
{
Name = "张三",
Age = 28
};
// 添加到上下文跟踪中，此时还未入库
context.Users.Add(user);
// 执行INSERT语句，返回受影响行数
int rows = context.SaveChanges();
Console.WriteLine($"保存成功，影响行数：{rows}");
}
变更跟踪与状态
EF Core通过实体的状态来决定生成什么SQL。常见状态包括：
- Added：实体将被插入
- Modified：实体将被更新
- Deleted：实体将被删除
- Unchanged：无变更，不会生成SQL
调用SaveChanges时，EF Core会扫描所有状态不为Unchanged的实体，按依赖顺序提交。
修改与删除示例
using (var context = new AppDbContext())
{
var user = context.Users.First(u => u.Name == "张三");
// 修改属性，上下文自动标记为Modified
user.Age = 30;
// 删除实体
var old = context.Users.First(u => u.Name == "李四");
context.Users.Remove(old);
// 一次提交包含UPDATE和DELETE
context.SaveChanges();
}
返回值与事务
SaveChanges返回int，表示受影响的数据库行数。在默认情况下，EF Core会把本次所有变更放在一个本地事务中，要么全部成功，要么全部回滚。
| 场景 | 行为 |
|---|---|
| 部分SQL失败 | 整体回滚，已跟踪状态不变 |
| 并发冲突 | 抛出DbUpdateConcurrencyException |
| 成功提交 | 实体状态变为Unchanged |
常见使用误区
频繁调用SaveChanges
在循环里每改一条就调用一次，会产生大量短连接和事务，严重拖慢性能。应当批量改完再统一保存。
using (var context = new AppDbContext())
{
for (int i = 0; i < 100; i++)
{
context.Users.Add(new User { Name = $"用户{i}" });
}
// 循环外一次性保存
context.SaveChanges();
}
忘记调用SaveChanges
很多初学者改完实体后发现数据库没变，就是因为漏了调用。在ASP.NET Core的Controller中，通常应在业务方法结尾显式保存，或依赖工作单元封装。
异步与取消
在高并发接口中建议使用SaveChangesAsync，避免阻塞线程：
public async Task CreateUserAsync(User user)
{
using var context = new AppDbContext();
context.Users.Add(user);
await context.SaveChangesAsync();
}
掌握SaveChanges的跟踪机制和提交时机，是写好EF Core数据层的基础。理清状态变化、控制提交频率，就能稳定高效地完成大多数业务持久化需求。
EF_CoreSaveChangesDbContext修改时间：2026-07-30 17:48:21