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<t>().Find(id)</t>或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 长什么样。
