绝大多数 web 请求场景下完全不需要手动关闭数据库连接；脚本结束时 mysqli 和 pdo 均自动释放资源，强行调用 mysqli_close() 或 $pdo = null 不仅多余，还易引发“couldn't fetch mysqli”等报错、干扰框架连接池。
PHP 最新版（截至 2026 年）中，**绝大多数 Web 请求场景下完全不需要手动关闭数据库连接**——脚本结束时 mysqli 和 PDO 都会自动释放资源。强行加 mysqli_close() 或 $pdo = null 不仅多余，还容易触发报错或干扰框架逻辑。
mysqli_close() 为什么经常报 “Couldn't fetch mysqli”？
这个警告本质是 PHP 在尝试操作一个已失效的连接句柄。常见原因：
- 连接本身创建失败（比如密码错误），
$conn是false或null，却直接传给mysqli_close($conn) - 用了面向对象风格
$mysqli = new mysqli(...)，又调了$mysqli->close()，脚本结束时析构器再执行一次，第二次就崩 - 连接变量是全局或被多个函数共享，某处已关过，别处又调一次
- 在 Laravel、ThinkPHP 等框架里手动关连接，结果破坏了连接池复用机制，后续查询可能拿到脏状态
PDO 连接设为 null 是不是必须？
不是必须，但安全可控。重点在于：$pdo->close() 根本不存在 —— PDO 没有这个方法。
-
$pdo = null会触发析构，释放连接，适合 CLI 长任务中提前切换数据库 - Web 请求中，函数内创建的
$pdo在函数返回后自动不可达，GC 会在脚本结束时处理，无需干预 - 不要用
unset($pdo)替代 —— 效果等价，但= null更直白，也避免在作用域外误读变量状态
持久连接（pconnect）能真正关闭吗？
不能。调用 mysqli_close() 或设 $pdo = null 对持久连接无效，它只是归还到连接池，等待下次复用。
- 确认是否用了持久连接：查代码里有没有
mysqli_pconnect()，或 PDO 构造时传了[PDO::ATTR_PERSISTENT => true] - 想真正断开？只能靠 MySQL 服务端超时（
wait_timeout）或 DBA 手动KILL连接 - 持久连接适合短生命周期 Web 请求，但不适合 CLI 守护进程 —— 容易因状态残留（如用户变量、事务未提交）导致后续查询异常
CLI 脚本里不关连接，真会撑爆 MySQL 吗？
会。而且来得很快。
- PHP-FPM 进程退出才释放连接；CLI 脚本若没显式清理，每次
new PDO()都新建物理连接 - 一个
while(true)循环里反复 new，不出几小时就触发Too many connections - 正确做法：用
try/finally或register_shutdown_function()兜底，确保连接释放；批量处理时，优先复用同一个$pdo实例，而非反复新建
真正要盯住的不是“怎么关”，而是“谁还在持有着连接”——尤其是 CLI 脚本、队列消费者、长循环里的 new PDO()。一个没注意的引用，就可能让连接卡在内存里不动声色地累积。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
