替换DbContext.Attach()：重新加载实体更新是否存在弊端？

你现在的思路很明确：用无跟踪查询拉取实体填充表单，保存时再从数据库重新加载一个带跟踪状态的实体，先对比RowVersion做并发校验，再把表单里的新数据映射到这个跟踪实体上完成保存。你封装的ReloadEntityAsync方法已经把重新加载和并发检查的逻辑处理好了。

但这套方案存在几个潜在弊端：

• 额外的数据库查询开销：每次更新都要多执行一次查询去拉取实体，在高并发场景下会增加数据库的读写压力，尤其是更新频繁的实体，会直接影响系统的吞吐量。
• 属性映射复杂度高：你需要手动将表单里的无跟踪实体属性逐一赋值到重新加载的跟踪实体上。如果实体结构复杂（比如包含多层嵌套的自有实体、关联属性），映射逻辑会变得繁琐，很容易遗漏属性，后期维护成本直线上升。
• 极小概率的并发窗口问题：虽然用RowVersion做了并发校验，但从重新加载实体到执行保存的这段时间里，仍有可能被其他用户/线程修改数据。RowVersion已经能覆盖绝大多数并发场景，但极端情况下还是会出现冲突（不过这种概率很低）。
• 自有实体的映射风险：就像你之前遇到的Address这类OwnsOne配置的自有实体，映射时必须确保嵌套的每个属性都赋值到位，否则照样会出现更新遗漏的情况，和之前Attach的问题本质类似，只是换了场景而已。
• 性能不如优化后的Attach方案：如果能解决Attach的状态标记问题，只需要一次更新操作即可完成保存，而你的方案需要一次查询加一次更新，在性能敏感的场景下，这个差距会被放大。

其实你之前遇到的Attach无法检测自有实体属性变化的问题，是因为EF Core默认会把Attach的实体标记为Unchanged，不会自动遍历嵌套属性检测变化。可以试试这些优化方案：

1. 手动标记自有实体状态：Attach主实体后，显式将自有实体设为Modified：

context.Attach(entity);
context.Entry(entity.Address).State = EntityState.Modified;

2. 直接使用Update方法：调用context.Update(entity)，EF Core会自动将实体及其所有关联的自有实体标记为Modified，不过这会更新所有字段，不管是否真的有改动。
3. 用TrackGraph自定义追踪逻辑：遍历实体图，自行控制哪些部分需要标记为更新：

context.ChangeTracker.TrackGraph(entity, e => {
    e.Entry.State = e.Entry.IsKeySet ? EntityState.Unchanged : EntityState.Added;
    // 对自有实体单独处理
    if (e.Entry.Metadata.IsOwned())
    {
        e.Entry.State = EntityState.Modified;
    }
});

总的来说，你当前的重新加载实体方案是可行的，适合实体结构简单、并发压力不大的场景，但存在额外的查询和映射成本。如果想优化性能，建议优先解决Attach的状态标记问题，减少不必要的数据库交互。

内容的提问来源于stack exchange，提问作者David Thielen