Db::connect() 不真正建连，需主动执行 SELECT 1 等轻量查询触发；生产环境应分别检查主从连接、设超时、防连接泄漏，并避免依赖 ping() 判定健康。
连接池里连不上，Db::connect() 不报错但查不出数据
ThinkPHP 的 Db::connect() 默认只校验配置是否合法，不真正发起连接；等你第一次执行 select() 或 query() 时才建连——这时候失败就晚了，业务可能已进入中间件或控制器。
- 用
Db::connect()->getRealSql()没用，它不触发连接 - 必须主动调用一次轻量查询，比如
Db::query('SELECT 1')或Db::table('')->count() - 生产环境建议加
try/catch包住健康检查逻辑，捕获PDOException和 ThinkPHP 封装的DbException - 注意：MySQL 连接超时（
wait_timeout）可能导致空闲连接在复用时突然断开，单次检查不能代表长期可用
用 ping() 方法判断连接是否存活，但 PHP 版本和驱动有坑
ThinkPHP 6.1+ 的 Connection 对象支持 ping()，但它底层调用的是 PDO 的 getAttribute(PDO::ATTR_CONNECTION_STATUS)（仅 MySQLi 支持），而原生 PDO 并不提供可靠连接状态检测。
- MySQLi 驱动下
ping()有效，返回true/false；PDO 驱动下多数情况直接返回true，不可信 - 别依赖
$db->ping()做服务探活，它容易误判“连接正常” - 更稳妥的做法是：先
ping()，再立刻执行SELECT 1，两者都通过才算健康 - 如果你用的是 PDO + Unix socket 或长连接池（如 Swoole），
ping()可能始终返回true，实际后续查询仍会失败
定时任务里做健康检查，Db::connect() 多次调用引发连接泄漏
每次调用 Db::connect() 都会新建一个 Connection 实例，若没显式释放或复用，在 CLI 环境（如 php think timer）中容易堆积未关闭的 MySQL 连接，最终触发 Too many connections 错误。
- 不要在循环或高频定时任务里反复写
$db = Db::connect() - 改用单例方式获取连接：
Db::name('user')->count()会自动复用默认连接池中的实例 - 如果必须手动管理，检查完后调用
$db->close()（仅对 MySQLi 有效；PDO 不支持真正关闭物理连接） - CLI 场景建议设置连接最大生命周期，例如在数据库配置中加
'break_reconnect' => true，避免复用僵死连接
监控接口返回 200 却掩盖了主库不可用的问题
很多团队把健康检查写成 HTTP 接口（如 /api/health），只检查「能否连上数据库」，却没区分主从——结果从库通、主库挂，接口照常返回 200，但写操作全失败。
- ThinkPHP 的读写分离模式下，
Db::connect()默认连的是读连接（read配置），INSERT/UPDATE才走写连接（write配置） - 健康检查必须分别测试读连接和写连接：
Db::master()->query('SELECT 1')和Db::slave()->query('SELECT 1') - 写连接检查建议用
INSERT INTO think_health_test (created_at) VALUES (NOW())+ 立即DELETE，避免污染数据 - 别省略错误上下文：记录具体失败的是哪个连接（
master还是slave）、哪台服务器 IP、错误码（如HY000或2006）
最麻烦的不是连不上，而是连得上但慢——网络抖动、锁表、慢查询队列堆积，都会让健康检查卡在 SELECT 1 上几十秒。超时时间得设得比业务 SQL 更激进，比如 500ms 内无响应就标为异常。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
