调用SaveChangesAsync抛出超时异常但数据库变更已保存的咨询

我正在使用EF Core 8.0.8版本搭配SQL Server数据库。近期因IT基础设施故障，数据库运行速度变慢，频繁出现查询超时问题。我们发现有时调用DbContext的SaveChangesAsync方法时会抛出超时异常，但检查数据库表后发现所有变更均已正确保存。

请问这是数据库或EF的bug吗？我一直以为SaveChangesAsync抛出异常时不会对数据库进行任何变更。还是说这是EF开发者设计的预期行为？

异常信息：

Microsoft.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
---> System.ComponentModel.Win32Exception (258): The wait operation timed out.

这既不是EF Core的bug，也不是SQL Server的bug，而是网络/超时时机引发的预期边缘情况，具体原因如下：

• 事务执行与超时的时机差：默认情况下，SaveChangesAsync会把所有变更封装在一个数据库事务中执行。如果SQL Server已经完成变更提交，但由于基础设施故障（比如网络延迟、服务器负载过高），EF Core客户端没在超时窗口内收到服务器的执行确认，就会抛出超时异常，但数据库端的变更已经生效。
• 客户端超时≠数据库执行失败：你遇到的是SqlClient的客户端超时，不是数据库端的执行超时。数据库可能已经完成操作，但客户端因等待过久而触发异常——这种“操作已完成但响应未达”的场景，是分布式系统中难以完全规避的不确定情况。
• 认知偏差的来源：正常情况下，若数据库在执行变更过程中超时，事务会回滚，变更不会保存。但“执行完成后无响应”属于例外场景，并非EF Core的设计缺陷，而是分布式环境下的客观问题。

应对方案：

• 临时延长命令超时：通过DbContext.Database.SetCommandTimeout(TimeSpan.FromSeconds(60));调整超时时间，缓解故障期间的异常频率，但这只是权宜之计。
• 实现幂等逻辑：如果业务允许，设计可重复执行的变更操作，避免因重复触发SaveChangesAsync导致的数据异常。
• 优先修复基础设施：排查并解决数据库性能瓶颈、网络不稳定等根源问题，才是彻底解决的关键。

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