EF Core 的
ChangeTracker是 DbContext 的核心机制，它不显眼，但决定了你改了什么、要不要存、怎么存。用对了，开发顺滑；忽略它，常会遇到“具有相同键值的实例已被跟踪”这类报错，或者修改不生效、删除变插入等意外行为。
ChangeTracker 跟踪什么？五种状态要分清
每个被上下文加载或显式附加的实体，都有一个 EntityState，共五种：
Detached：没被跟踪，比如 new 出来的对象，或调用过context.Entry(e).State = EntityState.DetachedUnchanged：从数据库查出来的，没动过属性，
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 长什么样。
