必须显式释放 pdostatement 和结果集，否则内存不会回收，因 pdo 默认启用游标缓存，$stmt 持有元数据和缓冲区，未 closecursor() 或 unset() 会导致引用计数不归零而内存泄漏。
必须显式释放 PDOStatement 和结果集，否则内存不会回收
为什么 PDO 查询后内存不自动释放
PHP 的 PDO 默认使用“游标缓存”（cursor caching），PDOStatement 对象本身持有结果集元数据和缓冲区；即使你 fetch() 完所有行，只要 $stmt 变量还存在、没被销毁或没调用 closeCursor()，Zend 就不会释放底层分配的内存。尤其在 CLI 长任务或循环查询中，每轮新增一个 PDOStatement，内存会线性上涨。
常见误判点：
-
unset($stmt)不够——若还有其他变量引用该对象（比如塞进数组或闭包里），引用计数不归零，内存卡住 -
fetch()后直接进入下一轮循环，没清空$stmt或没断开与$pdo的关联 - 用了
PDO::FETCH_CLASS但类构造失败或未定义__destruct()，实例残留
释放内存的三步实操法
不是“查完就完”，而是“查→取→清”闭环操作。以下代码适用于 PHP 8.2+，含 MySQL/PostgreSQL 等主流驱动：
- 执行查询后，立刻调用
$stmt->closeCursor()：它会释放结果集缓冲区，并将语句重置为可重用状态（不影响$stmt本身） - 若不再需要该语句对象，用
unset($stmt)销毁变量；若需复用（如预处理语句），至少确保每次execute()前已closeCursor() - 对大结果集，避免
fetchAll()全量加载——改用fetch()迭代 + 即时处理 +unset($row)，防止临时数组累积
示例：
for ($i = 0; $i prepare("SELECT id, name FROM users LIMIT 1000 OFFSET ?");
$stmt->execute([$i * 1000]);
<pre class="brush:php;toolbar:false;">while ($row = $stmt->fetch()) {
processUser($row);
unset($row); // 显式释放单行引用
}
$stmt->closeCursor(); // ✅ 关键：释放结果集缓冲
unset($stmt); // ✅ 销毁语句对象}
检查是否真释放了：用 memory_get_usage(true) 验证
别靠感觉，跑多轮验证差值。在循环前后插入监控：
- 循环前：
echo "start: " . memory_get_usage(true) . "\n"; - 每轮末尾：
echo "after round $i: " . memory_get_usage(true) . "\n"; - 跑 50 轮，观察是否稳定（±几 KB 波动）；若每轮涨 16KB 以上，说明有泄漏未断开
注意：必须用 memory_get_usage(true)（带 true 参数），否则 Zend 内存池缓存会让数值失真。
容易被忽略的隐性泄漏点
除了 PDOStatement，这些也得手动管：
-
PDO::setAttribute(PDO::ATTR_EMULATE_PREPARES, false)开启后，某些驱动（如旧版 pgsql）可能延迟释放绑定参数内存，建议关闭模拟预处理并确认驱动版本 - 用
new PDO(...)创建连接后未unset($pdo)或未让其自然离开作用域——长生命周期连接会持有一堆内部资源 - 框架封装（如 Laravel 的
DB::select()）返回的是数组而非PDOStatement，看似安全，但若内部没调closeCursor()或用了fetchAll()，照样泄漏 - 错误处理中
var_dump($stmt)或error_log(print_r($stmt, true))会触发__debugInfo()，导致临时对象生成并滞留
最稳妥的做法：只要不用了，立刻 closeCursor() + unset()，不依赖 GC 触发时机。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
