Entity Framework SaveChanges工作原理及事务处理疑问

嘿，我来帮你拆解EF是怎么把代码里的对象操作转成数据库请求的，还有你这个测试场景里的细节~

EF的整个转换过程其实是靠状态追踪+差异分析+SQL生成+事务管控这几个环节配合完成的，具体到你的代码步骤：

• 第一步：追踪实体状态
  当你执行var entity = context.Entities.First()时，EF的DbContext会把这个捞出来的实体加入内部的状态管理器，标记为Unchanged状态，同时偷偷记录下它所有属性的原始值（比如A和B一开始的取值）。
• 第二步：捕获属性变更
  当你修改entity.A = "TST"和entity.B = "WrongValue"时，EF会通过两种方式感知变化：如果你的实体是EF生成的代理类（比如用了virtual属性），会实时触发状态更新；如果是普通实体类，EF会在你调用SaveChanges()前做一次属性值对比。不管哪种方式，最终都会把这个实体的状态改成Modified，并记录每个属性的「原始值」和「当前值」的差异。
• 第三步：前置验证与SQL生成
  调用SaveChanges()后，EF会先跑一波前置验证：检查数据注解（比如[Required]、[ForeignKey]）或Fluent API定义的规则，比如外键值是否在关联表的主键集合里。如果验证不通过，直接抛出异常，不会生成任何SQL。
  如果验证通过，EF会根据实体的状态和属性差异生成对应的SQL语句——对你的场景来说，就是一条UPDATE语句，大概长这样：

  UPDATE [Entities]
  SET [A] = @p0, [B] = @p1
  WHERE [Id] = @p2;
  

• 第四步：事务管控
  默认情况下，SaveChanges()会把所有要执行的SQL包装在一个数据库事务里。如果任何一步SQL执行失败（比如你的B是无效外键，SQL Server会抛出外键约束冲突错误），EF会立即触发事务回滚，所有变更都不会落到数据库里。

你把B设为无效外键的操作，会在两个环节被拦截：

1. EF前置验证拦截：如果你的实体配置了正确的外键关系（比如用[ForeignKey]标注了B属性），EF在SaveChanges()时会先检查这个外键值是否存在于关联表中。发现无效后直接抛出DbUpdateException，根本不会向数据库发送任何SQL请求。
2. 数据库约束拦截：如果EF没做前置验证（比如你关闭了验证，或者外键配置有问题），EF会把UPDATE语句发给SQL Server，但数据库的外键约束会直接拒绝这个请求，返回错误。此时EF会回滚整个事务，所以数据库里的数据不会有任何变化。

你提到“奇怪的是……”，虽然没说完，但结合这个场景，常见的疑惑点大概有这两个：

• 为什么监控不到任何SQL请求？：这是因为EF的前置验证就失败了，根本没走到生成SQL的步骤。你可以给DbContext加个日志输出（比如在构造函数里加LogTo(Console.WriteLine)），或者捕获DbUpdateException查看InnerException，就能看到具体的验证错误。
• 为什么单独改A能成功，一起改就全失败？：这就是事务的原子性在起作用——EF默认保证SaveChanges()里的所有变更要么全成功，要么全失败，不会出现“只改了A没改B”的半成状态，完全符合数据库事务的ACID特性。

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