EF Core实体状态与变更追踪：原理、状态转换与避坑指南

很多人在项目里用 EF Core 用得挺熟，CRUD 一把梭，但一旦碰到性能问题、诡异的“无法跟踪多个实体实例”报错，或者更新时莫名其妙把整行都改了，就有点抓瞎。这些问题的根子，大多出在同一个地方：没搞清楚 EF Core 的实体状态和变更追踪机制到底是怎么运作的。这篇就专门把这块掰开揉碎讲清楚，从五种状态的定义、状态切换的路径、底层快照追踪的原理，到实际项目里怎么利用这些机制写出高效又安全的代码，一次说透。

1. 为什么你必须搞懂实体状态和变更追踪

先问个最直接的问题：EF Core 怎么知道你的实体是新增、修改还是删除？答案是它并不“猜”，全靠一套内部的记账系统——变更追踪器（ChangeTracker）。你每次从数据库查出来的实体、手动 new 出来的实体、甚至压根没打算存库的临时对象，都会被这个追踪器归类到某一种状态里。而 SaveChanges 要做的事，就是根据这些状态生成对应的 Insert、Update、Delete 语句。

这意味着什么？意味着只要你对状态的认知是模糊的，写出 bug 只是时间问题。举两个最常见的翻车场景：

• 场景一：从数据库查出一个实体，改了它的属性，但是用 AsNoTracking() 查的。结果调用 Update 方法时发现状态不对，或者在 SaveChanges 后数据库纹丝不动，因为 EF 压根没在管这个对象。
• 场景二：在循环里反复将同一个 Id 的实体 Attach 到同一个 DbContext，结果抛出 InvalidOperationException: The instance of entity type 'X' cannot be tracked because another instance with the same key value is already being tracked。很多人第一次见这个异常都懵了，以为是并发问题，其实纯粹是变更追踪器不允许同一个上下文中出现同主键的两个被追踪实体。

这两个坑，属于只要你理解了状态模型，就能一眼看穿的那种级别。更别说性能层面：对于一个包含几千个实体的查询结果，如果只是做只读展示却全量启用了追踪，变更追踪器内部会为每个实体维护快照，内存占用和 CPU 消耗都会被白白浪费。理解状态和追踪，是你写出高性能 EF Core 代码的必修课。

2. 五种实体状态的本质与判定标准

EF Core 的实体状态一共有五种，定义在 EntityState 枚举里，它们分别是：Detached、Unchanged、Added、Modified、Deleted。搞懂这五个词，基本就搞懂了一大半。

2.1 Detached（游离态）：EF 完全不知道它的存在

Detached 指一个实体没有被当前 DbContext 的变更追踪器跟踪。它可以是你在代码里 new 出来的全新对象，也可以是曾经被查询出来、但之后上下文被 Dispose 掉的旧对象。对于当前上下文而言，这个实体就是空气，你改它任何属性，SaveChanges 都不会有任何反应。

这个状态特别容易出现在 WebAPI 场景。请求进来，你用 EF 查出一个实体返回给前端；下一个请求进来，用户把这个实体（或者改过的 JSON）又传了回来。此时它跟当前请求的 DbContext 没有任何关系，就是妥妥的 Detached 状态。如果这时候你直接把它传给 Update 方法，EF 会执行“全字段更新”——一个不小心，用户在界面上没填的字段就会把数据库里原有的值覆盖成空。

2.2 Unchanged（未变更）：一切正常，无需生成 SQL

Unchanged 是最理想的“读出来没改过”的状态。实体被变更追踪器跟踪，同时它当前的值和内部的快照值完全一致。SaveChanges 时，EF 对这类实体的结论是“没变化，不生成任何 Update 语句”。

判断一个实体是否处于 Unchanged 的简单方法是看 context.Entry(entity).State，同时也可以看 context.ChangeTracker.DebugView.ShortView 输出的追踪列表。在实际项目中，这是大部分从数据库查询出来、还没经过任何赋值的实体的归属状态。

2.3 Added（新增）：下次 SaveChanges 执行 Insert

Added 表示这个实体需要插入数据库。你不用手动设置主键，因为如果是自增主键且值为默认值（比如 int 主键的 0 或 Guid 的全空），EF Core 会在生成 Insert 语句时把它标记为“需要数据库生成”。

一个容易忽略的细节是：当你把一个实体标记为 Added 后，如果该实体还关联着一整个对象图（比如主表对象下面挂着 List<子表实体>，子表实体又引用了别的字典表实体），并且这些关联对象也都是 Detached 状态，EF Core 的默认行为是将整个可达对象图里所有 Detached 的实体全部标记为 Added。这在某些简单场景下很省事，但在复杂模型下，会导致你只想加一条主记录，结果把一堆关联的字典数据也重复插入。

2.4 Modified（已修改）：Update 语句的源头

Modified 状态很好理解，实体被追踪，且属性值发生了变化，或者是你手动通过 Entry(entity).State = EntityState.Modified 强制指定的。SaveChanges 时会生成 Update 语句。

这里的关键点在于，Update 语句更新的字段范围，取决于你如何进入 Modified 状态：

• 由快照对比检测到变化进入的 Modified：只会更新那些真正发生变化的属性列。比如你的实体有 20 个字段，只改了 1 个属性，SQL 里就只 Set 这 1 列。
• 直接设置整个实体 State 为 Modified，或调用 DbSet.Update()：EF 会把所有属性都标记为 Modified，SQL 里就会 Set 所有列。这在某些需要“全字段覆盖更新”的场景是有效的，但如果只是前端传了个不完整的 DTO，就可能造成字段被意外覆盖。

所以并不是看到 Modified 就够了，还得搞清楚它是“部分列 Modified”还是“整行 Modified”，这是后面要重点展开的。

2.5 Deleted（已删除）：只做主键条件删除

Deleted 状态代表实体将在下次 SaveChanges 时被删除。EF 生成 Delete 语句时，默认只会以主键作为 Where 条件，不会关心其它属性是否被修改过。这意味着你把一个实体标记为 Deleted，即使它的某些普通属性值和数据库里不一样，删除操作依然能正常执行（只要主键没变），因为 SQL 的 Where 只匹配主键。

这里有个并发相关的坑：如果在高并发场景下，你需要“期望影响行数为 1，但实际影响 0 行”时抛并发异常，单纯靠默认的 Deleted 状态是不够的，因为Update/Delete的Where条件里没有版本字段（如 RowVersion）。要启用并发令牌，你需要给实体配置 IsConcurrencyToken()，EF 才会把版本字段也加入 Where 条件。

3. 状态切换路径与对象图整体分析

这五种状态并不是孤立的，它们之间可以互相转换，而且转换的“通路”非常有规律。很多人用 EF Core 出问题，就是没搞明白这些通路。

3.1 核心通路一：从 Detached 到 Added / Modified / Deleted

对于 Detached 的实体，你有几条明确路径可以走：

• DbSet.Add(entity) 或 context.Add(entity)：把实体和它的可达对象图中所有 Detached 实体的状态设为 Added。
• DbSet.Update(entity) 或 context.Update(entity)：标记实体的所有属性为 Modified（即整行更新）；同时对于关联对象图中 Detached 的子实体，如果是主键已设置的值类型，会被标记为 Modified；如果主键没有值（比如自增主键为 0），则会被标记为 Added。这个逻辑比较复杂，也是很多人说“Update 怎么把子表加重复了”的根源。
• DbSet.Remove(entity) 或 context.Remove(entity)：把实体状态设为 Deleted。注意，如果这个实体当前是 Detached 状态，Remove 会对它先做一次 Attach，再标记为 Deleted。
• context.Entry(entity).State = EntityState.XXX：这套写法最直接，粒度也最细，可以单独控制根实体而不会自动影响导航属性集合里的子对象（这在“只想更新主表、不动子表”的场景特别有用）。

我个人的经验是，日常编码里除非是极其简单的增删改，否则尽量少用 Update(entity) 这种“无脑全标”的方法，多用 Entry(entity).State 配合属性级别的操作，控制力强很多，也不容易误伤。

3.2 核心通路二：从其它状态回到 Unchanged / Detached

已追踪的实体如果要“撤销修改”，可以调用 context.Entry(entity).Reload()，它会重新从数据库加载一次数据并覆盖当前实体属性，状态会回到 Unchanged。如果要彻底让追踪器忘记这个实体，可以调用 context.Entry(entity).State = EntityState.Detached，这样后续 SaveChanges 就不会再管它。

这里要特别注意：Detach 一个实体并不会自动 Detach 它的导航属性子实体。如果对象图很庞大，你想彻底清理上下文，最稳妥的办法是直接用 context.ChangeTracker.Clear()。这个方法在 EF Core 5.0 之后引入，相当于把整个上下文的追踪器重置，比以前一个个 Detach 干净利落得多。它还会把当前正在进行的一些状态重置，所以用完记得确认没有未保存的更改。

3.3 对象图的级联追踪规则

刚才反复提到对象图。EF Core 在追踪一个实体时，如果配置了导航属性，它不会只追踪你传入的那个根实体，而是会顺着导航属性把所有能到达的关联实体一并纳入追踪范围。这是很多诡异问题的真正来源。

举个例子：

csharp复制public class Order
{
    public int Id { get; set; }
    public Customer Customer { get; set; }
    public List<OrderItem> Items { get; set; }
}

假如你的 Order 已经存在于上下文中，且处于 Unchanged 状态。此时你给它赋了一个新的 Customer 对象，而这个 Customer 是前端传过来、只带了 Id 的 Detached 实体。你本意可能只是关联订单和已有的客户，并不想修改 Customer 表。但因为对象图追踪规则的存在，EF Core 会尝试把这个 Customer 也纳入追踪，结果可能变成给它执行了一次 Insert（如果主键不可识别）或者把整行 Update 了一遍。

规避办法有两种：一种是干脆不在导航属性上赋整个实体对象，而是使用“外键属性直接赋值”的方式，比如有 CustomerId 属性就直接赋 Id；另一种是使用 context.Entry(customer).State = EntityState.Unchanged 告诉 EF“这个客户是已存在的，别动它”。方案一更符合 DDD 里“聚合根只暴露 ID 引用”的实践，方案二则适合快速修补遗留代码。

4. 变更追踪的底层工作过程与两个核心模型

理解了状态机，接下来有必要看看 EF Core 内部是怎么感知状态变化的。

4.1 快照追踪的工作过程

EF Core 默认使用快照追踪（Snapshot Tracking）。当一个实体被查询出来并开始被跟踪时，EF Core 会为它内部的每个属性拍一张“快照”，保存在一个影子字典里。之后每次调用 SaveChanges（或者显式调用 ChangeTracker.DetectChanges()）时，EF Core 会拿当前属性值和快照值逐一对比，发现哪个属性变了，就把对应属性标记为 Modified。

这个机制有两个重要的时间点：

• 属性赋值那一刻，不会立刻改变状态。你给实体赋了新值，但此刻状态还是 Unchanged，要等到 DetectChanges 被触发，才会变成 Modified。
• SaveChanges 的第一步就是自动调用 DetectChanges()，所以状态通常会在保存前被刷新，但如果你在 SaveChanges 之前就依赖 State 做判断（比如编写一些审计逻辑），可能就会看到状态还没更新的中间态。

4.2 何时自动触发 DetectChanges

DetectChanges 会在以下时机自动触发：

• 调用 SaveChanges / SaveChangesAsync 之前。
• 首次访问 ChangeTracker 的一些成员，比如 Entries()、DebugView。
• 部分查询操作执行之前（如果上下文里可能有悬而未决的修改）。
• DbSet.Add / Update / Remove 等方法执行过程中。

这也就是说，你循环一千次修改一千个实体的属性，期间如果不触发 DetectChanges，那状态不会同步变化，但一旦 SaveChanges，EF Core 会集中对比一次，性能上还算能接受。但如果你的循环里每一步都访问了 context.Entry(entity).State（这会触发 DetectChanges），那性能损耗就比较明显了，因为相当于每改一次属性就做了一次全量快照对比。

4.3 通知追踪（Change Tracking Proxies）

除了快照追踪，EF Core 还支持基于通知的追踪，它要求实体类继承自特定的基类（由 Microsoft.EntityFrameworkCore.Proxies 包提供），并且所有属性必须是 virtual 的，EF 在运行时生成代理类，属性 setter 被改写，赋值时会直接通知变更追踪器“这个属性变了”。

通知追踪的最大好处是不需要等 DetectChanges 做全量快照对比，属性一变，状态立刻更新，性能在大量“逐属性修改、频繁 SaveChanges”的场景下会更好。但代价也很大：实体类被代理侵入，要求无参构造且属性全 virtual，这跟很多现有项目里使用的 POCO 类很不兼容，而且调试时看到的是代理类型而不是真实类型，容易让人困惑。我的建议是：除非你非常明确需要这种高频率修改场景，否则踏踏实实用默认的快照追踪就好，它足够稳，坑也最少。

5. 实操中如何精细化控制状态：Entry 与属性级别操作

前面讲了那么多理论和原则，现在落到代码层面，看看实际项目里怎么玩转这套状态机制。

5.1 使用 Entry 获取状态，指定属性级修改

如果你只想更新实体的某几个字段，而不是整行更新，最精确的方式是：

csharp复制var user = await _context.Users.FindAsync(id);

// 这个实体已在上下文追踪中，Unchanged
user.NickName = "新的昵称";

// 此时状态仍是 Unchanged，因为还没触发 DetectChanges
// 但只要 SaveChanges，状态就会自动变成 Modified（仅 NickName 列）
await _context.SaveChangesAsync();

这是最推荐的做法：查出来，改需要改的属性，保存。EF 只更新真正变化的列，其他列保持不变，天然安全。

但如果你的场景是 DTO 传入、不想先查一次数据库，又只想更新指定的几个字段，可以这样手动指定属性修改：

csharp复制var user = new User { Id = 1, NickName = "新的昵称" };

_context.Users.Attach(user);
_context.Entry(user).Property(u => u.NickName).IsModified = true;

await _context.SaveChangesAsync();

这段代码会把 user 以 Unchanged 状态附加到追踪器，然后手动把 NickName 标记为 Modified。SaveChanges 时生成的 SQL 仅包含 SET [NickName] = @p0 WHERE [Id] = @p1。这个招数在实现“PATCH 式更新”的 API 时非常实用，也避免了先查数据库再更新带来的额外查询开销。

注意：如果你对某个属性调用了 IsModified = false，但实体本身其它属性已经被整体标记为 Modified（比如用了 Update 方法），那单独设 false 只会让该属性不进入更新列，其他列还是照常更新。所以控制顺序很重要，别指望着靠 IsModified=false 来“抹掉” Update 方法的全字段更新。

5.2 Attach、Add 和 Update 方法的行为差异速查

这里整理一个表格，便于日常查阅：

这个表格里的“有主键”判断标准是什么？EF Core 默认会去看主键属性值是否等于 CLR 默认值（如 int 为 0、Guid 为全空、string 为 null），不是默认值就认为它已经存在于数据库。所以如果你搞了个非自增主键但在业务上主键值就是 0（极少见），那 EF 会误判，需要手动处理。

5.3 通过 Reload 和 Clear 进行状态修复

实体在上下文里待久了，难免状态会“脏”。有两个常用操作可以救命：

csharp复制// 如果你怀疑实体的当前值已经被改乱，想从数据库重新拉一次
await _context.Entry(user).ReloadAsync();
// 执行后 user 的状态回到 Unchanged，属性值变成数据库里的最新值

// 如果你的上下文是个长生命周期对象，攒了一堆追踪信息，想一次性清空
_context.ChangeTracker.Clear();

ChangeTracker.Clear() 是 EF Core 5.0 之后新加的，强烈推荐替代老旧的“循环 Detach”写法。它把当前追踪的所有实体全部 Detach，比手动逐个处理性能好得多，也不会漏掉那些你通过导航属性间接搞进来的实体。注意，调用 Clear 后，之前实体上的“待保存修改”状态也会被一并清掉，所以只应该在明确不需要保存当前修改时使用。

6. 避坑指南：常见陷阱、报错信息与性能问题

这一节把实战中踩过的坑集中复盘一下，都是血泪经验。

6.1 典型报错：无法跟踪多个同主键实体

这个报错信息大概是这样的：

InvalidOperationException: The instance of entity type 'User' cannot be tracked because another instance with the same key value for {'Id'} is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached.

出现这个问题的原因，一句话说就是同一个 DbContext 的追踪器里，已经有一个相同主键的实体，你又试图把另一个相同主键的新对象 Attach 或 Add 进来。最常见的触发场景是 WebAPI 里，同一个 DbContext 被请求级共享（比如用了 scoped 生命周期），请求处理中先查了一次 user，后来又从外部数据源反序列化出另一个 user，然后做 Update。

解决方案有几种：

• 如果你需要的是“更新已存在实体的属性”，先找到已追踪的那个实例（比如通过 _context.Users.Local.FirstOrDefault(u => u.Id == id)），把新值赋给它，再 SaveChanges。
• 如果其实不需要追踪已查询出来的实体，查询时用 AsNoTracking() 即可。
• 如果两个实体真的没法避免同时出现，那就把旧的 Detach 掉再操作新的，或者干脆换一个干净的 DbContext 来执行这次更新。

6.2 只读查询务必使用 AsNoTracking

很多人只会在查询结果需要修改时关心追踪，但其实在只读展示场景使用追踪是纯亏。一个包含几千行数据、每行带有多个导航属性的查询，如果不加 AsNoTracking，EF 会为所有返回实体创建快照并维护状态，内存占用可轻松翻倍。SaveChanges 时，还要对快照做逐属性比较，白白消耗 CPU。

EF Core 里有两种关闭追踪的方式：

• 查询级别：_context.Users.AsNoTracking().ToList()
• 全局级别：_context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking

全局关闭后，所有查询默认不追踪，需要修改时再显式加 AsTracking()。这对于“读多写少、API 只返回 DTO 给前端”的项目特别合适。但要注意：全局关闭后，如果你写关联数据的代码依赖延迟加载（Lazy Loading），由于没有追踪，延迟加载可能失效（除非导航属性在序列化之前已经被显式访问）。更进一步说，不追踪的实体上如果开启了 Lazy Loading，EF 会抛异常，因为脱离了上下文范围。所以这个选项要全局考虑清楚再用。

csharp复制// 推荐用法：需要批量做只读报表时
var reportData = await _context.Orders
    .AsNoTracking()
    .Include(o => o.Items)
    .Where(o => o.CreatedAt > startDate)
    .ToListAsync();
// 这里拿到的数据只用于展示和统计，不会被 SaveChanges 跟踪

6.3 SaveChanges 过程中的性能与批量操作建议

如果你需要一次更新几千行数据，最常见的做法是循环查出来、逐条改、最后 SaveChanges。这种写法在几十条以内问题不大，但几百上千条时会明显变慢，因为快照对比的粒度是逐实体、逐属性的，几千行下来 DetectChanges 就成了性能瓶颈。

几个替代方案：

• 使用 ExecuteUpdate / ExecuteDelete（EF Core 7.0+）：这是直接执行批量 UPDATE/DELETE 语句的方式，不经过变更追踪器，性能极优。比如 _context.Users.Where(u => u.IsActive == false).ExecuteDelete()。这类方法最大的特点是不受上下文追踪状态影响，即使实体在追踪中，也不会触发 SaveChanges 的自动更新。
• 把多条独立的增删改拆成多次 SaveChanges：每次 SaveChanges 都会做一次 DetectChanges，如果你拆得太细反而更慢，所以要把握好粒度。
• 可以考虑关闭 AutoDetectChanges：_context.ChangeTracker.AutoDetectChangesEnabled = false，在批量循环里手动控制何时调用 DetectChanges。不过这是比较进阶的玩法，不建议新手一上来就用，因为它会让 SaveChanges 之前的状态评估变得不可预期，容易漏更新。

实战中我的原则是：100 行以下的更新，直接默认追踪 + SaveChanges，代码最清晰；超过 100 行或者需要“按条件更新/删除”的，用 ExecuteUpdate/ExecuteDelete，把性能问题消灭在代码设计层面，不要试图靠微调追踪器来弥补。

6.4 跨上下文操作与实体状态判断的实操经验

还有一种很容易踩坑的情况：你在一个方法里 new 了两个 DbContext（不管是手动 new 还是通过工厂），从 contextA 查出了一个实体，又传给 contextB 去 SaveChanges。由于每个 DbContext 的追踪器是相互独立的，contextB 看到这个实体的时候，它就是 Detached。你要在 contextB 执行 Updated 操作，或者要正确判断状态，都得在 contextB 里重新 Attach 或查询一次。

如果项目里用了 DbContextFactory（比如 Blazor Server 或 Worker Service 这种长生命周期宿主），建议给每个“业务操作单元”都使用独立的 DbContext，不要试图跨上下文传实体。每当你发现自己把 entity 当作参数在两个 service 之间传来传去，就要警惕追踪上下文已经换掉了。

判断一个实体在当前上下文中到底处于什么状态，可以用这句：

csharp复制var state = _context.Entry(entity).State;

如果实体完全不被追踪，你会得到 Detached。而如果你的设计里实体可能来自其它上下文，或者压根没被加载过，直接访问 Entry(entity) 不会有异常，它只会显示 Detached，不会有副作用。

7. 一个端到端的实战：更新订单及其明细

说了一堆理论，最后用一个最常见的电商场景把整套状态流转串起来：前端提交一个“编辑订单”请求，订单可能改了收货人、改了几个明细项的数量，也可能删掉了一些明细。

DTO 大概是这样的：

csharp复制public class UpdateOrderRequest
{
    public int OrderId { get; set; }
    public string ReceiverName { get; set; }
    public List<OrderItemDto> Items { get; set; }
}

public class OrderItemDto
{
    public int Id { get; set; }           // 0 表示新增
    public int OrderId { get; set; }
    public string ProductName { get; set; }
    public int Quantity { get; set; }
    public bool IsDeleted { get; set; }   // 前端标记删除
}

第一种方案，也是最“朴素”的方案：查出订单和明细，逐条对比，更新需要改的，删除被标记删除的，新增需要新增的。

csharp复制public async Task UpdateOrder(UpdateOrderRequest request)
{
    var order = await _context.Orders
        .Include(o => o.Items)
        .FirstOrDefaultAsync(o => o.Id == request.OrderId);

    if (order is null) throw new NotFoundException();

    order.ReceiverName = request.ReceiverName;
    // 此时 order 还是 Unchanged，直到 SaveChanges 时 DetectChanges
    // 但它已被跟踪，所以 SaveChanges 后只有 ReceiverName 列会更新

    var incomingIds = request.Items
        .Where(i => i.Id != 0)
        .Select(i => i.Id)
        .ToHashSet();

    // 删除：数据库中有的 but 前端没传或标记删除的
    foreach (var existingItem in order.Items.ToList())
    {
        if (!incomingIds.Contains(existingItem.Id) ||
            request.Items.Any(i => i.Id == existingItem.Id && i.IsDeleted))
        {
            _context.OrderItems.Remove(existingItem);
        }
    }

    // 更新和新增
    foreach (var itemDto in request.Items)
    {
        if (itemDto.IsDeleted) continue;

        if (itemDto.Id != 0)
        {
            var existingItem = order.Items.FirstOrDefault(i => i.Id == itemDto.Id);
            if (existingItem is not null)
            {
                existingItem.Quantity = itemDto.Quantity;
                existingItem.ProductName = itemDto.ProductName;
                // 这几个属性一旦在 SaveChanges 时变化，就只更新对应列
            }
        }
        else
        {
            order.Items.Add(new OrderItem
            {
                ProductName = itemDto.ProductName,
                Quantity = itemDto.Quantity
            });
            // 新对象 Add 到导航集合时，因为它还没被追踪，而且 Orders 已被追踪，
            // EF 会在 DetectChanges 时自动识别并把它标记为 Added
        }
    }

    await _context.SaveChangesAsync();
}

这段代码充分利用了“先查出来再修改”这个最安全的路径，状态怎么流转基本是自动完成的。但要注意：当我调用 _context.OrderItems.Remove(existingItem) 时，如果这个明细实体还关联着其它子实体、且数据库有外键约束，可能会因为删除顺序问题抛异常。比如外键是级联删除的，EF 会自己处理；但如果限制为 Restrict，就要先删除引用它的数据才行。

第二种方案则更“手写控制”。假设出于性能考虑，你十分确定这次只需要更新订单头和明细数量，不想先把整棵对象图从数据库捞出来（能减少一大轮查询），可以做一次“增量更新”：

csharp复制public async Task UpdateOrderHeaderAndQuantities(UpdateOrderRequest request)
{
    // 1. 只更新订单头：Attach 一个只有主键和需要更新字段的实体
    var orderStub = new Order { Id = request.OrderId };
    _context.Orders.Attach(orderStub);
    orderStub.ReceiverName = request.ReceiverName;
    _context.Entry(orderStub).Property(o => o.ReceiverName).IsModified = true;

    // 2. 批量更新明细数量
    // 先查出所有涉及的历史明细（只查 Id 和 Quantity）
    var existingItems = await _context.OrderItems
        .Where(i => i.OrderId == request.OrderId)
        .Select(i => new OrderItem { Id = i.Id, OrderId = i.OrderId, Quantity = i.Quantity })
        .ToListAsync();

    // 这里有个坑：Select 投影出来的实体也是被追踪的，但除了 Id、OrderId、Quantity 之外，
    // 其它属性是默认值，所以如果想做“部分字段更新”，不能直接改整个实体的 State
    // 我只想改 Quantity，所以用 Entry 的方式精确控制
    // 更好的做法是接住投影实体，赋完值后把每个实体单独的属性标记 IsModified
}

说白了，手动控制状态这条路很灵活，但代码复杂度也跟着上来了，普通人日常开发还是老老实实用第一种“查出来改”的方案，遇到性能瓶颈再做针对性优化，这样维护成本最低。

8. 高频问题排查速查表

总结几个项目里高频出现的问题和解决思路，做成速查表，真遇到问题可以直接对号入座。

这张表不敢说包治百病，但基本覆盖了我这些年做 .NET 后端遇到的状态与追踪相关的高频问题。

9. 最后分享一个实用习惯

我个人习惯是在项目里封装一个小的扩展方法，专门用于“把前端 DTO 转成实体并做部分更新”，比较实用，分享给你。

csharp复制public static void MarkModified<TEntity, TProperty>(
    this DbContext context,
    TEntity entity,
    Expression<Func<TEntity, TProperty>> propertyExpression)
    where TEntity : class
{
    context.Entry(entity).Property(propertyExpression).IsModified = true;
}

这样在 Controller 或 Service 里，写部分更新就能非常简洁：

csharp复制var user = new User { Id = dto.Id };
_context.Users.Attach(user); // 状态 Unchanged
_context.MarkModified(user, u => u.NickName);
_context.MarkModified(user, u => u.Avatar);
await _context.SaveChangesAsync();

这个扩展方法内部做的事情，本质上是把你“手动控制状态”的动作收敛到一处，逻辑清晰，团队里新人也容易看懂。不过要提醒一句：使用这段代码前，务必确保 User 实体没有被当前上下文跟踪，否则 Attach 时会报重复跟踪的错。如果可能被跟踪，先查出来再走普通赋值路径即可。

状态和追踪不是那种“看了就会”的知识，它更像一张地图，你多走几遍弯路、多看几次异常堆栈，慢慢就形成条件反射了。希望这篇能帮你省掉一些我自己当年绕过的弯路。