mysqli_close() 仅关闭普通连接，对持久连接无效；pdo 需设 $pdo = null 才真正释放连接，且必须同时清理 pdostatement 和结果集以避免内存泄漏。
mysqli_close() 真的关掉了连接吗？
不一定。调用 mysqli_close($conn) 后，普通连接会断开，但持久连接（由 mysqli_pconnect() 创建，或通过 PDO 的 PDO::ATTR_PERSISTENT => true 启用）只是归还到连接池，MySQL 侧仍维持着 TCP 连接。
常见错误现象：mysqli_close() 返回 true，但 show processlist 里还能看到对应连接处于 Sleep 状态，且持续数小时不消失。
- 先查代码：有没有
mysqli_pconnect()？或者 PDO 初始化时传了[PDO::ATTR_PERSISTENT => true] - 持久连接下，
mysqli_close()是空操作，不用调；强行调也不会报错，但无意义 - 普通连接（
mysqli_connect()）可调用，但非必须——脚本结束时 PHP 自动释放
PDO 怎么关才真正生效？
PDO 没有 close() 方法，$pdo->close() 会直接报 Fatal error: Call to undefined method。正确做法是切断所有引用，让对象被销毁。
使用场景：CLI 脚本、长循环、多数据库切换时，必须主动释放，否则可能耗尽 max_connections。
- 核心操作：
$pdo = null—— 这会触发 PDO 析构函数，真正断开底层连接 - 如果还有
PDOStatement对象（比如$stmt），也得设为null，否则 PDO 实例引用计数不为 0，连接不会释放 - 不要只写
unset($pdo)；$pdo = null更明确、更可靠 - 在 try/finally 或
register_shutdown_function()中兜底，防止异常跳过释放逻辑
结果集和语句对象不清理，内存就爆了
很多人只关连接，却忘了 mysqli_result 和 PDOStatement 这两个“隐形吃内存大户”。尤其处理百万级数据导出时，不手动释放，PHP 内存占用会线性上涨，最终 OOM。
常见错误现象：CLI 脚本跑着跑着报 Allowed memory size exhausted，但 memory_get_usage() 显示没明显泄漏 —— 很可能是结果集资源卡在引用计数里。
- mysqli 下：遍历完
$result后立刻执行mysqli_free_result($result)，再unset($result)（后者非必需，前者必须） - PDO 下：
fetch()或fetchAll()不持有结果集句柄，但PDOStatement对象本身要清：执行完就$stmt = null - 避免在循环里反复
$pdo->prepare($sql)；应提前 prepare，循环中只$stmt->execute()
CLI 脚本里最容易漏掉的三件事
Web 请求有生命周期兜底（PHP-FPM 进程退出时自动收尾），但 CLI 脚本靠自己。一个没关的连接，在长时间运行的队列任务或定时脚本里，就是 MySQL 的慢性毒药。
性能影响：每个未释放连接占一个 max_connections 配额；默认值通常 151，撑满后新请求直接被拒，整个服务雪崩。
- 所有数据库操作完成后，显式执行
mysqli_close($conn)（普通连接）或$pdo = null（PDO） - 加上
register_shutdown_function(function () use ($conn) { mysqli_close($conn); });做保底 - 如果用了流式查询（
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false），务必确保while ($row = $stmt->fetch())完整遍历完，否则后续查询会报Cannot execute queries while other unbuffered queries are active
最常被忽略的一点：不是“关连接”这个动作难，而是忘记“关之前先清结果集、清语句、清所有引用”。连接只是表象，资源滞留的根子往往在那几个没设成 null 的 $stmt 变量里。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
