如何利用 do-while 确保数据库连接在重试逻辑中至少尝试建立一次

do-while这个关键字，很多人的第一反应是“至少执行一次”——没错，但它并不能自动处理异常、延迟或者重试逻辑。要真正实现一个靠谱的重试机制，你需要手动去管理连接尝试、错误判定、指数退避，以及最容易被忽略的状态重置。

do-while 本身不保证连接成功，只保证至少执行一次

很多开发者一看到“重试”这个词，就想当然觉得 do-while 是标准答案——其实不然。它只是一个语法结构：先无条件执行一次循环体，再根据条件决定要不要继续。它不会替你捕获异常、不会自动等待间隔，更不会帮你识别哪些错误是暂时的。如果你在 catch 块里没有手动重置状态或更新重试计数，那循环要么直接跑飞（死循环），要么连第二次都不会尝试。

用 do-while 实现“至少连一次 + 可控重试”的典型写法

关键是什么？不是语法本身，而是如何把连接动作、错误判定、延迟控制和退出条件组织进去。常见的坑是，把整个 try/catch 塞进循环条件里，结果逻辑乱成一锅粥。

推荐结构（以 C# 为例）：

int attempt = 0;
int maxRetries = 3;
TimeSpan baseDelay = TimeSpan.FromSeconds(5);
bool connected = false;
SqlConnection conn = null;

do
{
    try
    {
        conn = new SqlConnection(connectionString);
        conn.Open();
        connected = true;
    }
    catch (SqlException ex) when (IsTransientError(ex))
    {
        attempt++;
        if (attempt <= maxRetries)
        {
            Thread.Sleep((int)baseDelay.TotalMilliseconds * (int)Math.Pow(2, attempt - 1)); // 指数退避
        }
    }
} while (!connected && attempt < maxRetries);

if (!connected)
    throw new InvalidOperationException("Failed to connect after " + maxRetries + " attempts");

需要特别留意几个细节：

• IsTransientError(ex) 必须自己实现，不能照搬别人的错误码列表——Azure SQL 和本地 SQL Server 的暂时性错误码并不完全一样，硬编码很容易漏掉某些场景。
• 延迟不能写成固定的 Thread.Sleep(5000)，连续失败时这样的做法会压垮服务端。建议采用指数退避，比如第一次等5秒，第二次10秒，第三次20秒，这样更温和。
• 必须显式管理 attempt 计数，do-while 不会自动帮你递增。
• 连接成功后要立刻跳出循环，否则下一次迭代又会新建 SqlConnection 实例，造成资源泄漏。

比 do-while 更稳妥的替代方案

在实际项目中，手写 do-while 容易漏掉边界情况。更推荐的做法有：

• 利用 ADO.NET 连接字符串参数：ConnectRetryCount=3; ConnectRetryInterval=5; —— 底层驱动会自动处理重试，根本不需要你写循环。
• 在 EF6 中启用 SqlAzureExecutionStrategy，它内部已经封装了重试次数、退避策略和事务一致性检查，用起来省心不少。
• 在云环境（如 Azure App Service）下，优先依赖平台级连接池和中间件重试能力，而不是自己写应用层轮子。

最后提醒一点：重试之前，有没有关闭上一个失败的连接？这点很容易被忽视。未释放的 SqlConnection 对象可能卡在 Connecting 状态，持续占用连接池名额，导致后续重试全部排队超时。这才是真正的隐患所在。