PDO连接未释放的根本原因是存在其他变量引用该对象，因PHP依赖引用计数，仅$pdo = null无法触发析构；常见引用源包括PDOStatement、全局数组、闭包、类属性等。
为什么$pdo = null 不一定释放连接
根本原因不是“没写断开语句”，而是PDO对象仍有其他变量在引用它。PHP的资源释放依赖引用计数，只要还有一个变量指向该PDO实例，$pdo = null就只是减少一次引用，不会触发析构。
常见被忽略的引用来源包括：
-
PDOStatement对象（比如$stmt = $pdo->prepare(...)）默认持有对父$pdo的隐式引用 - 全局数组缓存了
$pdo（如$GLOBALS['db'] = $pdo），未清空该键值 - 闭包或回调中使用了
use ($pdo)，且该闭包仍存活（例如注册为事件监听器、传入异步任务） - 类属性中保存了
$pdo，但对象本身未销毁（如单例类未重置、或被静态变量长期持有）
unset() 和 $var = null 的实际效果差异
两者在资源释放上本质相同：都是将变量的引用计数减1。区别仅在于语义和可读性。unset($pdo)明确表达“丢弃这个变量”，而$pdo = null是赋值操作，可能掩盖真实意图。
但要注意：
立即学习“PHP免费学习笔记（深入）”；
- 如果
$pdo是函数内局部变量，函数返回后自动销毁，无需手动unset或赋null - 如果
$pdo是类的public或protected属性，仅unset($obj->pdo)不够——必须确保整个对象也被销毁，或显式设为null -
unset()不能用于超全局变量（如$_SESSION里的PDO对象），只能用$_SESSION['db'] = null
如何确认连接是否真正释放
不能只看PHP变量是否置空，要验证MySQL端是否断开。最直接的方式是在脚本中执行：
echo "Before close: ";
system("ss -tn | grep :3306 | wc -l");
$pdo = null;
echo "After null: ";
system("ss -tn | grep :3306 | wc -l");
注意：ss比netstat更轻量，适合调试。若输出数字未下降，说明仍有其他引用存在。
另一个验证点是MySQL的SHOW PROCESSLIST：在连接刚创建后查一次，再在$pdo = null后立刻查一次，观察对应Host和Command（应从Query变为Sleep，最终消失）。
循环中重复new PDO却未释放的典型陷阱
批量处理时容易写出这样的代码：
for ($i = 0; $i < 100; $i++) {
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec("INSERT INTO log VALUES ($i)");
// 忘记 $pdo = null 或 unset($pdo)
}
表面看每次迭代都新建一个$pdo，但PHP不会自动清理前一次的变量——因为$pdo是同一作用域内的同名变量，新赋值会覆盖旧值，**旧PDO对象只有在被新值覆盖的瞬间才减少一次引用**。如果中间有PDOStatement残留，它仍能拖住连接。
更安全的做法是强制隔离作用域：
- 把数据库操作封装进函数，让
$pdo成为函数局部变量 - 或在循环体内用
{ $pdo = new PDO(...); ...; $pdo = null; }加代码块限定作用域 - 避免在循环中反复
new——改用单连接+事务批处理
真正难缠的不是“怎么断开”，而是“谁还在拿着它”。查引用比写null更重要。
