DB::connection('read')->getPdo() 卡住因PDO默认静默失败且无超时，TCP握手阻塞在从库宕机但网络未断开时；应配timeout=3并用select('SELECT 1')探活。
为什么 DB::connection('read')->getPdo() 会卡住而不报错
因为 Laravel 默认的从库连接在底层使用 PDO 的 PDO::ATTR_ERRMODE 是 PDO::ERRMODE_SILENT，连接失败或超时不会抛异常，而是返回 false 或静默失败。加上 Laravel 的连接池和重试机制，getPdo() 可能阻塞在 TCP 握手阶段，尤其当从库宕机但网络未断开（如防火墙拦截、数据库进程僵死）时。
- 真实场景中，用
try/catch包裹DB::connection('read')->select('SELECT 1')更可靠，它强制触发实际查询而非仅拿连接句柄 - 务必设置
'timeout' => 3在数据库配置的read连接里，否则默认可能等 30 秒以上才超时 - 不要依赖
DB::connection('read')->getPdo() !== null判断健康，这个值在连接失败后仍可能非空（PDO 对象已创建但未成功握手）
Laravel 定时任务里怎么安全探活从库并自动下线
不能直接在 App\Console\Commands\CheckReadDatabase 中调用 DB::purge('read') 然后重建连接 —— Laravel 的连接是单例且共享的，purge 会影响所有正在使用的请求上下文。正确做法是维护一个独立的「探活连接」，只用于检测，不参与业务查询。
- 新建一个专用连接配置，比如叫
read_health，复用read的 host/port/credentials，但单独配'timeout' => 2和'options' => [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION] - 在命令中用
DB::connection('read_health')->select('SELECT 1')，捕获Illuminate\Database\QueryException和PDOException - 检测失败后，往缓存写个标记：
Cache::put('db_read_unhealthy', true, 300)（5 分钟），业务代码读取该标记决定是否跳过从库 - 切记：不要修改
config/database.php运行时配置，Laravel 不支持热更新连接配置
业务代码里如何绕过不健康的从库而不改模型写法
最轻量的方式不是重写 Model::on('write')，而是利用 Laravel 的连接解析器，在查询前动态干预。核心是覆盖 Illuminate\Database\Connectors\ConnectionFactory 的行为，但更稳妥的做法是用中间件 + 查询监听器。
- 在
App\Providers\AppServiceProvider::boot()中注册查询监听：DB::listen(...)，检查当前连接名是否为read且缓存存在db_read_unhealthy标记 - 监听到从库查询时，用
DB::reconnect('write')强制切换到主库（注意：这会丢弃当前事务上下文，所以仅适用于只读场景） - 如果业务有强一致性读需求（如刚写完立刻查），必须显式用
Model::on('write')->find($id)，不能依赖自动读写分离 - 避免在 Eloquent 关系加载（
$user->posts）中隐式走从库 —— 关系默认继承父模型连接，若父模型用了主库，关系也会走主库；反之则可能误走故障从库
DB::connection('read')->getDatabaseName() 返回空字符串说明什么
说明连接对象已初始化，但尚未完成认证或数据库选择（USE database），常见于连接池复用旧连接后，PDO 句柄处于“半打开”状态。这不是 Laravel 特有，是 PDO 层面对 MySQL 协议的实现细节。
- 这个现象常出现在连接被复用但上一次查询后连接被服务端关闭（如 wait_timeout 超时），而客户端没感知，下次调用
getDatabaseName()就返回空 - 它比
getPdo() === null更早暴露问题，可作为轻量探测信号之一，但不能单独作为健康判断依据 - 配合
DB::connection('read')->getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS)查看状态，正常应返回类似MySQL server has gone away或OK，但注意这个方法本身也可能触发重连
真正难处理的是那种“连接能建、查询能发、但结果永远不返回”的半死状态 —— 它躲得过大多数简单 ping，只能靠带 timeout 的真实查询+缓存标记双保险。别信任何不发 SQL 的探测方式。
