EF Core 的连接弹性（Connection Resiliency）核心是自动重试因网络抖动、数据库瞬时不可用等导致的暂时性故障。最直接有效的配置方式就是使用 EnableRetryOnFailure 方法，它会为 DbContext 启用内置的重试执行策略。
基础启用方式（推荐默认用法）
对 SQL Server、PostgreSQL（Npgsql）、MySQL（Pomelo）等主流提供程序，只需在配置 DbContext 时调用
EnableRetryOnFailure()即可启用默认策略： SQL Server 默认识别错误码如 40613、40197、1205 等； PostgreSQL 识别 08006、08001 等连接类错误； 默认重试次数为 6 次，延迟采用指数退避（1s → 2s → 4s → …）； 无需额外判断异常类型，框架自动过滤非暂时性错误（如主键冲突、语法错误）。
示例（ASP.NET Core 中注册 DbContext）：
services.AddDbContext(options =>options.UseSqlServer(connectionString, sqlOptions =>
sqlOptions.EnableRetryOnFailure()));
自定义重试参数
当默认策略不满足业务场景（比如云环境波动大、或需更激进/保守的重试），可显式指定参数：
maxRetryCount：最大重试次数（默认 6，建议设为 5–10）； maxRetryDelay：单次最大延迟（默认 30 秒，避免长等待阻塞请求）； errorNumbersToAdd：补充自定义可重试的 SQL 错误号（如 SQL Server 的 2、53、10054）； 注意：errorNumbersToAdd是“追加”，不是“替换”——原有默认错误仍生效。
示例（自定义 8 次重试，最长延迟 20 秒）：
options.UseSqlServer(conn, o => o.EnableRetryOnFailure(maxRetryCount: 8,
maxRetryDelay: TimeSpan.FromSeconds(20),
errorNumbersToAdd: new[] { 2, 53 }));
事务中必须手动包装重试逻辑
启用了
EnableRetryOnFailure后，普通查询和
SaveChangesAsync()会自动重试。但一旦你显式开启事务（
BeginTransactionAsync()），EF 就无法安全重试整个事务块——因为部分操作可能已提交。 此时若在事务内发生暂时性错误，会抛出
InvalidOperationException：“已配置的执行策略不支持用户启动的事务”； 正确做法：用
DbContext.Database.CreateExecutionStrategy()获取执行策略，把整个事务逻辑包进委托里执行； 该策略会在失败时完整重放整个委托（含 BeginTransaction → SaveChanges → Commit），确保原子性。
连接字符串级补充配置（配合使用）
EnableRetryOnFailure处理的是命令执行阶段的失败，而连接建立阶段的弹性还需靠连接字符串参数：
ConnectRetryCount=5：驱动层连接尝试次数（ADO.NET 层）；
ConnectRetryInterval=10：每次重连间隔（秒）；
Connection Timeout=30：单次连接超时，避免卡死； 这两类机制（驱动层连接重试 + EF 命令重试）建议同时启用，形成双保险。
例如连接字符串片段：
Server=...;Database=...;ConnectRetryCount=5;ConnectRetryInterval=10;Connection Timeout=30;
基本上就这些。关键不是堆参数，而是理解重试边界——普通操作开箱即用，事务要手动兜底，连接建立和命令执行要分层防护。
