DB::connection()->getPdo() 是最轻量的数据库连通性验证方式，仅建立底层 PDO 连接而不执行 SQL；需 try/catch 捕获异常，成功返回 PDO 实例，失败则抛出连接拒绝或超时错误。
用 DB::connection()->getPdo() 最快验证连通性
连不上数据库时，DB::connection()->getPdo() 是最轻量的探测方式——它不执行 SQL，只尝试建立底层 PDO 连接。一旦抛出异常，基本就是配置或网络问题。
常见错误现象：SQLSTATE[HY000] [2002] Connection refused 或 Connection timed out；不是 Laravel 报错，而是 PDO 底层拒绝连接。
- 必须在
try/catch中调用，否则直接崩溃（Laravel 默认不捕获 PDO 异常） - 不要用
DB::table('users')->count()测试——它会触发查询、走 Query Builder、还可能因表不存在而误判 - 如果用了读写分离，
DB::connection('write')和DB::connection('read')要分别测
Artisan 命令 php artisan tinker 里快速手检
开发环境调试最顺手的方式：进 tinker，一行命令敲完立刻知道结果，不用写路由、不用启 HTTP 服务。
使用场景：CI 脚本前手动确认、部署后现场排查、同事交接时快速验环境。
- 运行
php artisan tinker，然后输入：DB::connection()->getPdo(); - 返回一个
PDO实例对象（类似PDO {#123}）说明通了；报错就停在这步 - 注意：tinker 默认用
config('database.default')的连接，不是.env里写的DB_CONNECTION值，得确认配置已重载（改完.env后要php artisan config:clear）
DB::connection()->reconnect() 不是“重连”，别当保命符用
这个方法名字有误导性：它不会自动恢复断开的连接，只是“关闭当前连接，下次用时新建”。真正发生连接中断（比如 MySQL kill 了闲置连接），Laravel 默认行为是抛异常，而不是静默重连。
性能影响：频繁调用 reconnect() 会额外增加一次连接握手开销，且无法解决事务中连接丢失的问题。
- 它只对“当前连接实例”生效，不影响其他请求或队列进程里的连接
- 想实现自动重试，得自己包一层
try/catch+reconnect()+ 再执行逻辑，但要注意事务上下文已失效 - 生产环境更推荐靠连接池（如 MySQL 的
wait_timeout配合 Laravel 的sticky配置）来减少中断，而不是依赖reconnect()
测试脚本里别漏掉 DB::disconnect()
写自动化检测脚本（比如健康检查接口或部署钩子）时，很多人只连不放，导致连接数缓慢上涨，尤其在容器或短生命周期环境中容易触发 MySQL 的 max_connections 限制。
容易踩的坑：PHP-FPM 模式下，连接可能被复用；但 CLI（如 Artisan 命令）每次都是新进程，不显式断开就会一直占着连接直到脚本结束。
- 测试完立刻加一句：
DB::disconnect(); - 如果用了多个连接名（如
mysql2），要指定：DB::disconnect('mysql2'); - 注意：断开后再调用
getPdo()会重新建连，不是报错——所以断开动作本身不会影响后续业务逻辑
数据库连接看似简单，但真实环境里最麻烦的往往不是“连不上”，而是“看起来连上了，但查不出数据”或者“偶尔超时”。关键得区分清楚：是网络层不通？认证失败？还是连接被中间件（如 ProxySQL）或云厂商（如 RDS 连接池）悄悄复位了——这些都得靠 getPdo() + 网络抓包 + MySQL 的 SHOW PROCESSLIST 组合判断。
