EF Core并发处理疑问及测试不稳定问题咨询

1. 捕获DbUpdateConcurrencyException后为何需要额外处理，直接重新获取数据会循环报错？ #

• 直接拉取数据库新数据后，EF Core的变更追踪器还保留着你最初加载的旧原始值（OriginalValues）。再次保存时，EF Core会用旧原始值和数据库当前值做乐观并发校验，自然还会触发DbUpdateConcurrencyException——这就是循环报错的根源，和上下文的一级缓存直接相关。
• 微软文档里的额外步骤（比如更新OriginalValues），核心是让变更追踪器同步数据库最新状态，确保下次保存时的并发校验用的是当前数据库的快照值，而非初始加载的旧值。

2. 何时需要结合本地与数据库值解决冲突？批量设置Original/CurrentValues可行吗？ #

• 当业务需要合并本地修改和数据库最新值时（比如用户编辑时，其他人改了其他字段，要保留用户修改的字段，同步其他字段的最新状态），就需要逐一处理属性。如果业务逻辑允许完全放弃本地修改、直接同步数据库最新值，那直接调用entry.OriginalValues.SetValues(databaseValues)和entry.CurrentValues.SetValues(databaseValues)完全可行。
• 文档里遍历属性逐一处理，是为了演示精细冲突解决的场景——比如区分哪些字段是用户主动修改的（需要保留），哪些是系统或其他用户修改的（需要同步）。批量设置是简化方案，只适用于无条件同步数据库的场景。

3. 并发调用UpdateMeasurementsForToday后，SummaryUpdates有时为1而非2？ #

• 大概率是你的更新逻辑没做乐观并发控制，或者冲突被静默忽略了。比如UpdateMeasurementsForToday可能是先查询数据、执行SummaryUpdates +=1、再保存，但没有给WeatherForecast实体加并发令牌（比如[Timestamp]或[ConcurrencyCheck]属性）。
• 两个请求同时查询到同一个初始SummaryUpdates值（比如0），各自加1变成1，先后保存时第二个请求会直接覆盖第一个的结果，最终就是1而不是2。解决方法是给SummaryUpdates或专门的并发字段加校验，这样第二个请求保存时会触发DbUpdateConcurrencyException，你可以在异常处理中重新拉取最新值、再次执行累加逻辑后保存。

内容的提问来源于stack exchange，提问作者Riyaz Vagapov