mysqli_close() 是显式关闭 MySQL 连接的函数，长时 CLI 脚本必须调用以避免占满 max_connections；PDO 则需设 $pdo = null 触发 GC 释放连接。
mysqli_close() 是什么，什么时候必须调用
mysqli_close() 是 mysqli 扩展中显式关闭 MySQL 连接的专用函数，它会立即断开 TCP（或 socket）连接，并释放 PHP 进程内对应的连接资源。但它不是“必须”调用的——非持久连接在脚本执行完后会自动释放，所以多数 Web 场景下不手动关也不会出错。
- 必须调用的场景：长时运行的 CLI 脚本（比如队列消费者、数据同步任务），否则连接会持续占用 MySQL 的
max_connections限额 - 调用后
$conn变量仍存在，但再用mysqli_query($conn, ...)会报致命错误：mysqli_query(): Couldn't fetch mysqli - 如果传入的是空值或无效资源，
mysqli_close()返回false，不抛异常，容易被忽略——建议加判断：
<?php
if ($conn && is_object($conn)) {
mysqli_close($conn) or trigger_error('mysqli_close failed', E_USER_WARNING);
}
?>
PDO 关闭连接为什么是 $pdo = null
PDO 没有提供类似 mysqli_close() 的显式关闭函数，标准做法是把连接对象赋值为 null。这不是“约定俗成”，而是由 PHP 的垃圾回收（GC）机制决定的：当 PDO 实例不再被任何变量引用时，PHP 会在下一个 GC 周期自动调用其析构器，触发底层连接释放。
- 不能写
unset($pdo)替代$pdo = null—— 如果还有其他变量引用该对象（比如$db = $pdo），unset($pdo)不会触发销毁 - 在 try-catch 中操作更安全：即使中间抛异常，也能确保
$pdo = null被执行（放在 finally 块里最稳妥） - 注意：PDO 构造失败时返回的是
PDOException，不会产生对象，所以$pdo = null前要确认对象确实存在
两者资源释放时机和可观测性差异
表面看都是“关连接”，但底层行为不同：mysqli_close() 是同步、即时、可验证的操作；而 $pdo = null 是异步、延迟、不可直接验证的释放。
-
mysqli_close()返回布尔值，能立刻知道是否成功；PDO 赋null总是成功，但连接实际断开时间取决于 GC 触发时机（通常很快，但不可控） - MySQL 服务端视角：mysqli 连接关闭后，
SHOW PROCESSLIST里对应条目立刻消失；PDO 对象置null后可能还残留几秒（尤其内存压力小、GC 未触发时） - 监控告警场景下，只依赖
mysqli_close()返回值不够——建议配合 MySQL 的Threads_connected状态变量做趋势比对
选哪个？别纠结驱动，先看你的连接生命周期
区别不在函数名或语法，而在你是否需要「确定性释放」。短请求（HTTP）基本不用管；长任务（CLI / daemon）才暴露真问题。
- 用 mysqli：适合简单脚本、对性能抠毫秒、且你习惯过程式风格；但要注意
mysqli_close()忘写或写错位置（比如放在 return 后）会导致连接泄漏 - 用 PDO：适合需扩展多数据库、写单元测试、或依赖异常统一处理的项目；但别指望
$pdo = null能精确控制释放时刻 - 最容易被忽略的一点：无论哪种方式，都解决不了“连接没建好就去关”的问题——比如
mysqli_connect()失败返回false，后续却仍传给mysqli_close()，会警告mysqli_close(): supplied argument is not a valid MySQL-Link resource
真正卡人的从来不是关连接的写法，而是连接本身有没有建稳、建对、建得及时。
