应主动执行 Db::connect($config)->query('SELECT 1') 并捕获异常来判断真实连接状态，而非依赖 Db::connect() 返回值；备用库需在启动时用 Db::setConfig('backup', $backupConfig) 预注册，切换时调用 Db::connect('backup') 复用配置。
连接失败时 Db::connect() 不抛异常，怎么判断是否真连上了？
ThinkPHP 默认的 Db::connect() 在配置错误或网络不通时，往往不直接抛异常，而是延迟到第一次执行 SQL（比如 select()）才报错。这导致“看似连接成功”，实际后续操作全崩。
真正可靠的判断方式是主动触发一次轻量级探活：
- 用
Db::connect($config)->query('SELECT 1')显式执行，捕获think\db\exception\DataNotFoundException或底层 PDO 异常 - 避免用
ping()—— ThinkPHP 的Connection类没有暴露该方法，且部分驱动（如 SQLSRV）不支持 - 注意：
$config必须是完整数组（含hostname、username等），不能复用默认配置键名，否则兜底逻辑会误判
备用数据库配置怎么注册进连接池，而不是写死在 try-catch 里？
手动在业务代码里写两套 Db::connect() + try/catch 是反模式。ThinkPHP 支持多配置共存，但需绕过默认初始化时机。
推荐做法是在应用启动阶段（如 app/common.php 或服务提供者中）预注册备用连接：
立即学习“PHP免费学习笔记（深入）”；
- 调用
Db::setConfig('backup', $backupConfig)，其中backup是自定义连接名 - 主连接失败后，不要 new 新实例，而是用
Db::connect('backup')复用已注册配置 - 切勿在控制器里重复调用
setConfig()—— 配置会被覆盖，且并发下可能污染其他请求 - 注意
setConfig()不校验配置合法性，错配字段（如把database写成dbname）会导致后续静默失败
切换备用库后，事务、查询日志、调试信息还生效吗？
不生效。ThinkPHP 的 Db 门面是单例，但底层连接实例是按配置名隔离的。一旦从 Db::connect()（默认）切到 Db::connect('backup')，所有上下文状态就断开了。
这意味着：
- 已开启的事务（
startTrans()）不会自动迁移，必须在备用连接上重新startTrans() -
Db::getLastSql()只返回最后一次在当前连接对象上的 SQL，跨连接不累计 - 调试面板里的 DB 耗时只统计当前连接实例的查询，主备切换后监控会断层
- 如果用了
think-swoole，连接实例可能被复用，务必在每次使用前检查$db->isConnected()，否则可能拿到一个已断开的旧连接
Db::connect() 报 PDOException: SQLSTATE[HY000] [2002] 怎么区分是配置错还是网络抖动？
这个错误码本身不区分原因，但可通过超时控制和重试策略缩小范围。
关键动作是调整连接参数而非改代码逻辑：
- 在数据库配置中显式设置
'params' => [PDO::ATTR_TIMEOUT => 3]，避免卡死在 DNS 解析或 TCP 握手 - 对
2002错误做有限重试（最多 1 次），间隔 100ms —— 真实网络抖动通常在毫秒级恢复，反复失败基本可判定为配置或服务宕机 - 注意：MySQL 的
connect_timeout是服务端参数，ThinkPHP 无法控制；真正起效的是客户端 PDO 的PDO::ATTR_TIMEOUT和 socket 层的default_socket_timeoutini 设置 - 若重试后仍报
2002，优先查hostname是否能ping通、telnet host port是否响应，而不是翻代码
最麻烦的其实是配置里混用了环境变量和硬编码——比如 hostname 来自 $_ENV，但 .env 文件漏写了，这种问题不会报错，只会连到 localhost，然后默默用错库。
