do-while仅保证循环体至少执行一次，不自动处理异常、延迟或重试逻辑；正确实现需手动管理连接尝试、错误判定、指数退避及状态重置。
do-while 本身不保证连接成功，只保证至少执行一次
很多人误以为 do-while 是“重试机制”的银弹，其实它只是语法结构：先无条件执行一次循环体，再判断条件是否继续。它不会自动捕获异常、不会等待间隔、也不会识别暂时性错误。如果你在 catch 块里没手动重置状态或更新重试计数，do-while 可能陷入死循环，或根本连第二次都不进。
用 do-while 实现“至少连一次 + 可控重试”的典型写法
关键不是语法本身，而是如何把连接动作、错误判定、延迟控制和退出条件组织进去。常见错误是把整个 try/catch 塞进循环条件里，导致逻辑混乱。
推荐结构（以 C# 为例）：
int attempt = 0;
int maxRetries = 3;
TimeSpan baseDelay = TimeSpan.FromSeconds(5);
bool connected = false;
SqlConnection conn = null;
<p>do
{
try
{
conn = new SqlConnection(connectionString);
conn.Open();
connected = true;
}
catch (SqlException ex) when (IsTransientError(ex))
{
attempt++;
if (attempt </p><p>if (!connected) throw new InvalidOperationException("Failed to connect after " + maxRetries + " attempts");</p>
注意点：
-
IsTransientError(ex)必须自己实现，不能只靠ex.Number列表硬编码——Azure SQL 和本地 SQL Server 的暂时性错误码不完全一致 - 延迟不能写成固定
Thread.Sleep(5000)，否则连续失败会压垮服务端；建议用指数退避（如 5s → 10s → 20s） - 必须显式管理
attempt计数，do-while不会自动递增 - 连接成功后要跳出循环，否则下次迭代仍会新建
SqlConnection实例，造成资源泄漏
比 do-while 更稳妥的替代方案
实际项目中，直接手写 do-while 容易漏掉边界情况。更推荐：
- 使用 ADO.NET 连接字符串参数：
ConnectRetryCount=3; ConnectRetryInterval=5;—— 这由底层驱动自动处理，无需自己写循环 - EF6 中启用
SqlAzureExecutionStrategy，它内部已封装了重试次数、退避策略和事务一致性检查 - 在云环境（如 Azure App Service）下，优先依赖平台级连接池和中间件重试能力，而非应用层轮子
真正容易被忽略的是：重试前是否关闭了上一个失败的连接？未释放的 SqlConnection 对象可能卡在 Connecting 状态，持续占用连接池名额，导致后续重试全部排队超时。
