当 MySQLi 启用 MYSQLI_REPORT_STRICT 模式时，连接失败会抛出 mysqli_sql_exception 而非返回 false，导致传统 if (!$conn) 判断失效；需改用 try-catch 捕获异常才能正确输出错误信息。
当 mysqli 启用 `mysqli_report_strict` 模式时，连接失败会抛出 `mysqli_sql_exception` 而非返回 `false`，导致传统 `if (!$conn)` 判断失效；需改用 `try-catch` 捕获异常才能正确输出错误信息。
在 PHP 中使用 mysqli_connect() 建立数据库连接时，开发者常依赖如下经典判断逻辑：
$conn = mysqli_connect($host, $user, $pass);
if (!$conn) {
die("Sorry we failed to connect: " . mysqli_connect_error());
}
然而，这段代码并非总能按预期工作——尤其当 MySQLi 的错误报告模式被设为严格（MYSQLI_REPORT_STRICT）时，连接失败将不再返回 false，而是直接抛出 mysqli_sql_exception 异常。此时 if (!$conn) 完全不会执行，程序中断于 mysqli_connect() 调用处，且默认错误信息（如“Connection refused”）可能被 PHP 错误处理器静默吞没或以原始异常堆栈形式暴露，导致你无法看到自定义的 "Sorry we failed to connect..." 提示。
✅ 正确做法：统一使用异常捕获
启用 MYSQLI_REPORT_STRICT（通常通过 mysqli_report(MYSQLI_REPORT_STRICT) 设置，或由某些框架/配置自动启用）后，必须使用 try-catch 显式处理连接异常：
<?php $servername = "localhost";
$username = "root";
$password = "";
// 启用严格异常模式（若尚未启用，可显式设置）
// mysqli_report(MYSQLI_REPORT_STRICT);
try {
$conn = mysqli_connect($servername, $username, $password);
echo "Connection was successful";
} catch (mysqli_sql_exception $e) {
// 注意：此处 mysqli_connect_error() 在异常模式下可能返回空字符串
// 推荐直接使用异常消息，更准确可靠
die("Sorry we failed to connect: " . $e->getMessage());
}
?>
? 关键提示：在 MYSQLI_REPORT_STRICT 模式下，mysqli_connect_error() 函数可能返回空值，因为错误上下文已由异常对象承载。因此，优先使用 $e->getMessage() 获取具体错误（如 Access denied for user 'root'@'localhost'），它比 mysqli_connect_error() 更健壮、信息更完整。
⚠️ 其他潜在原因排查清单
- PHP 错误报告级别过高：若 display_errors = Off 或 error_reporting 屏蔽了警告，异常可能被静默忽略。请确认开发环境启用 error_reporting(E_ALL); ini_set('display_errors', 1);。
- MySQL 服务未运行：确保 mysqld 进程正在本地监听（如 sudo service mysql status）。
-
权限或认证插件限制：MySQL 8.0+ 默认使用 caching_sha2_password 插件，而旧版 PHP 扩展可能不兼容；可临时切换用户认证方式：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY ''; FLUSH PRIVILEGES;
- 防火墙或端口阻塞：确认 localhost:3306 可达（telnet localhost 3306 或 nc -zv localhost 3306）。
✅ 最佳实践建议
- 始终启用异常捕获：无论是否明确设置了 MYSQLI_REPORT_STRICT，都推荐用 try-catch 包裹连接逻辑，提高健壮性；
- 避免裸 die()：生产环境应记录错误日志（如 error_log()），而非向用户暴露敏感信息；
- 考虑 PDO 替代方案：PDO 默认以异常模式运行（PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION），API 更现代、跨数据库兼容性更好。
通过适配异常处理机制，你不仅能准确显示连接失败原因，还能为后续查询、事务等操作建立统一的错误处理基础。
