ChangeTracker 是 DbContext 的核心跟踪机制，管理实体的五种状态（Detached、Unchanged、Added、Modified、Deleted），决定增删改操作如何生成 SQL；状态随查询、添加、修改、删除等操作自动流转，必要时需手动干预 Entry 状态以避免重复跟踪或实现软删除。

EF Core 的 ChangeTracker 是 DbContext 的核心机制，它不显眼，但决定了你改了什么、要不要存、怎么存。用对了，开发顺滑；忽略它，常会遇到“具有相同键值的实例已被跟踪”这类报错，或者修改不生效、删除变插入等意外行为。

ChangeTracker 跟踪什么？五种状态要分清

每个被上下文加载或显式附加的实体，都有一个 EntityState，共五种：

• Detached：没被跟踪，比如 new 出来的对象，或调用过 context.Entry(e).State = EntityState.Detached
• Unchanged：从数据库查出来的，没动过属性，SaveChanges() 不生成 SQL
• Added：刚 Add() 进上下文，还没进库，下次 SaveChanges() 执行 INSERT
• Modified：查出来后改了属性（或手动设为 Modified），下次 SaveChanges() 执行 UPDATE
• Deleted：调用 Remove() 或设为 Deleted，下次 SaveChanges() 执行 DELETE

常见操作：查、改、删时状态怎么变？

状态不是手动写死的，而是随操作自动流转，但你要知道触发点：

• 用 context.Set().Find(id) 或 FirstOrDefault() 查——实体进上下文，状态是 Unchanged
• 直接 new 对象 + context.Add(e)——状态变成 Added
• 查出对象后改属性（如 e.Name = "新名字"）——EF Core 自动检测并转为 Modified（无需手动设）
• 查出对象后调 context.Remove(e)——状态变为 Deleted
• 想跳过跟踪直接读数据？加 .AsNoTracking()，返回对象永远是 Detached

手动干预状态：什么时候必须用 Entry？

自动跟踪很省心，但有些场景得自己接管状态：

• 你有一个带主键的对象（比如 new User { Id = 123, Name = "李四" }），想让它走 UPDATE 而不是 INSERT——用 context.Entry(user).State = EntityState.Modified
• 查了一个实体 A，又通过其他方式（比如 API、缓存）拿到同一主键的实体 B，再一起更新——EF Core 会报重复跟踪错误。解决办法之一：把 A 先 Detach，再处理 B
• 做软删除时，在 SaveChanges() 里遍历 ChangeTracker.Entries()，发现实现了 ISoftDelete 的实体且状态是 Deleted，就改成 Modified 并设 IsDeleted = true

调试和观察：看看 ChangeTracker 在记什么

开发时怀疑状态不对？两行代码就能看清：

• Console.WriteLine(context.ChangeTracker.DebugView.ShortView); —— 简洁版，只显示类型+状态
• Console.WriteLine(context.ChangeTracker.DebugView.LongView); —— 详细版，含所有属性值、原始值、导航关系
• 遍历所有被跟踪项：foreach (var e in context.ChangeTracker.Entries()) { Console.WriteLine($"{e.Entity.GetType().Name}: {e.State}"); }

基本上就这些。ChangeTracker 不复杂，但容易忽略——它不抛异常，却默默决定你的 SQL 长什么样。