mysqli_connect()返回false时必须立即调用mysqli_connect_error()获取具体错误，否则无法定位Connection refused、Access denied或Unknown host等失败原因。
mysqli_connect() 不是万能的快捷键，它只在参数对、环境通、权限足的前提下才返回有效连接对象；否则直接返回 false，且不抛异常——这是最常被忽略的前提。
为什么 mysqli_connect() 返回 false 却没报错？
默认情况下，mysqli_connect() 失败时不触发异常，只返回 false。如果你写了 if (!$conn) { die("失败"); } 却没调用 mysqli_connect_error()，就只能看到“失败”两个字，完全不知道是用户名错、密码错、数据库不存在，还是 MySQL 服务根本没起来。
常见错误现象：
-
Connection refused：MySQL 服务未运行，或端口被防火墙拦截 -
Access denied for user：用户名/密码不匹配，或该用户无权从当前 host（如localhostvs127.0.0.1）登录 -
Unknown database：dbname参数指定的库名不存在（注意：这不会导致连接失败，但后续查询会报错）
实操建议：
- 务必在
die()中拼接mysqli_connect_error()，例如：die("连接失败: " . mysqli_connect_error()); - 测试时先去掉
dbname参数，只连服务器，确认基础连接通了再加库名 - 用
telnet localhost 3306或nc -zv localhost 3306手动验证端口可达性
localhost 和 127.0.0.1 在 mysqli_connect() 中真的一样吗？
不一样。MySQL 客户端库对 localhost 有特殊处理：它会强制走 Unix socket（Linux/macOS）或命名管道（Windows），跳过 TCP/IP 栈。而 127.0.0.1 明确走 TCP/IP。
立即学习“PHP免费学习笔记（深入）”；
这意味着：
- 如果 MySQL 配置禁用了 socket（比如
skip-networking未注释，或bind-address = 127.0.0.1但 socket 文件路径不对），localhost就会连接失败 - 如果 MySQL 只监听 socket（
skip-networking开启），用127.0.0.1会超时 - 用户权限也分
'user'@'localhost'和'user'@'127.0.0.1'，二者互不兼容
实操建议：
- 开发环境优先用
127.0.0.1，行为更可预测 - 线上部署若明确走 socket，可显式传
socket参数，例如：mysqli_connect("localhost", $u, $p, $db, null, "/var/run/mysqld/mysqld.sock") - 检查用户权限时，用
SELECT User,Host FROM mysql.user;确认实际匹配的是哪一行
面向过程写法和面向对象写法，选哪个？
两者底层调用一致，mysqli_connect() 本质就是 mysqli::__construct() 的别名。区别只在语法风格和错误处理惯性。
关键差异点：
- 面向过程：连接失败返回
false，必须手动查mysqli_connect_error() - 面向对象：
$mysqli = new mysqli(...)失败时仍返回对象，但$mysqli->connect_error属性可用；若开启异常模式（mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT)），则直接 throw 异常
实操建议：
- 新项目建议用面向对象 + 异常模式，错误堆栈更清晰，不用反复写
if (!$res) - 维护老代码时，别强行改写风格，保持
mysqli_connect()+mysqli_connect_error()组合的一致性即可 - 避免混用：不要用
mysqli_connect()创建连接，再拿结果去调$conn->query()—— 这会报致命错误，因为返回的是资源（PHP 7+ 是 object），不是mysqli实例
连接后不关闭，会出什么问题？
PHP 脚本结束时会自动释放连接资源，所以短生命周期脚本（如普通 Web 请求）不显式关闭一般不出事。但以下场景容易踩坑：
- 长时运行的 CLI 脚本（如队列消费者），连接闲置太久可能被 MySQL 的
wait_timeout（默认 8 小时）断开，下次查询直接报MySQL server has gone away - 高并发下，每个请求都新建连接却不释放，可能快速耗尽 MySQL 的
max_connections限制（默认 151） - 使用连接池或持久连接（
mysqlnd的pconnect）时，不关闭会导致连接复用逻辑紊乱
实操建议：
- Web 场景无需主动
mysqli_close()，让 PHP 自动收尾 - CLI 脚本中，执行完关键操作后立即
mysqli_close($conn)，或改用mysqli::ping()检测连接有效性再复用 - 永远不要依赖“脚本结束=连接安全释放”，尤其在 fork、pcntl 或 Swoole 等非标准执行模型中
