mysqli_connect()返回false时需先用if(!$conn)判断并调用mysqli_connect_error()获取具体错误，再通过mysqli_ping()检测连接活跃性，避免误用mysqli_query()验证。
连接失败时，mysqli_connect() 返回 false，但仅靠这个判断不够——它无法区分“连接被拒绝”“认证失败”还是“数据库不存在”。真正可靠的验证，得在连接建立后主动探测状态，而不是只看初始化那一瞬。
mysqli_connect() 后必须立刻检查 $conn 是否为 false
这是第一道防线，但容易漏掉细节：
-
mysqli_connect()失败时返回false，不是抛异常，所以要用if (!$conn)判断，不能依赖try/catch - 错误信息要从
mysqli_connect_error()拿，不是$conn->error（后者在连接未建立时会报 Notice） - 如果用面向对象写法
new mysqli(...)，构造失败时不会抛异常，而是把$mysqli->connect_error设为非空字符串，此时$mysqli->connect_errno也非零
连接建立后用 mysqli_ping() 检测活跃性
很多场景下，连接看似成功，但实际已断开（比如 MySQL 服务重启、防火墙超时中断、中间代理丢包）。mysqli_ping() 是唯一轻量且语义明确的保活探测方式：
- 它不执行 SQL，只发一个 ping 包，开销极小
- 返回
true表示连接仍可用；返回false说明连接已失效，需重连 - 注意：不能在连接句柄为
false时调用，否则触发 Warning - 典型误用：
if (mysqli_ping($conn) === false) { mysqli_close($conn); $conn = mysqli_connect(...); }
避免用 mysqli_query() 做连接验证
有人习惯执行 SELECT 1 来“试试看”，这其实引入了额外风险：
- 如果数据库权限受限（比如用户只有
SELECT权限但没默认库），mysqli_query($conn, 'SELECT 1')可能因无默认库而失败，误判为连接问题 - 如果连接是带
dbname参数建立的，但该库已被删，mysqli_query()会报错，而mysqli_ping()仍可能成功——说明连接本身没问题，只是上下文失效 -
mysqli_query()触发查询日志、慢查统计等副作用，高频验证会污染监控指标
命令行快速验证：php -r 最适合部署排查
不需要写文件，直接终端跑一行就能定位是环境问题还是配置问题：
php -r "\$c = new mysqli('localhost', 'root', 'pass', 'test'); echo \$c->connect_error ?: 'ok';"
输出为空或 ok 表示连接参数和网络都通；输出类似 Access denied for user... 或 Connection refused 就能立刻锁定问题类型。注意别漏掉单引号转义，否则 shell 会提前解析变量。
真正难的不是“怎么写检测代码”，而是理解 mysqli_connect() 成功 ≠ 数据库服务可用 ≠ 当前连接可执行查询。每个环节的失败原因和可观测信号都不同，混用检测手段反而掩盖真实瓶颈。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
