PDO连接对象被闭包捕获后内存不释放，因为闭包形成强引用，使$pdo无法被GC判定为不可达；即使作用域结束，只要闭包仍存在于事件回调、静态容器或未解绑监听器中，$pdo及其底层资源就持续驻留内存。
为什么PDO连接对象被闭包捕获后内存不释放
因为闭包（function() use ($pdo) {}）会形成强引用，让$pdo对象无法被垃圾回收器（GC）判定为“不可达”。即使脚本已离开作用域，只要闭包还存在（比如注册为事件回调、存入静态容器或未解绑的监听器），$pdo及其底层资源（如MySQL连接句柄、结果集缓存）就一直驻留内存。
常见错误现象：
- 调用
memory_get_usage(true)发现每次执行含闭包的逻辑，内存增长几 MB 且不回落 -
debug_zval_dump($pdo)显示refcount≥ 2，其中至少一个指向闭包的zend_closure结构 - 脚本结束前手动
unset($pdo)无效——闭包内部仍持有引用
如何确认闭包是否持有了数据库连接
分两步验证：先看引用关系，再查闭包绑定变量。
使用debug_zval_dump()检查连接对象状态：
debug_zval_dump($pdo); // 输出类似：object(PDO)#1 (0) refcount=3
若refcount明显高于 1（尤其在简单场景下），说明有外部引用未清理。
检查闭包绑定的变量：
- 用
ReflectionFunction获取闭包的getStaticVariables()，但注意它只返回use中显式声明的变量名，不递归展开对象属性 - 更直接的方式：在注册闭包前打点，记录
spl_object_id($pdo)，之后在疑似泄漏点用gc_collect_cycles()+ 再次debug_zval_dump()比对refcount变化 - 若你用的是 Laravel 或 Symfony，检查是否误将
$pdo或 Query Builder 实例传入tap()、when()、事件监听器等高阶函数——它们内部常构造闭包
避免闭包引用PDO的三种安全写法
核心原则：不把连接对象本身塞进use，改用参数传递、ID标识或延迟获取。
- 用参数代替
use：array_map(function ($item) use ($pdo) { ... }, $data)→ 改为array_map(function ($item, $pdo) { ... }, $data, array_fill(0, count($data), $pdo))（虽略冗余，但确保闭包不持有引用） - 只传连接标识（如DSN片段或配置数组），在闭包内按需新建轻量
PDO（适合只读、短生命周期操作） - 用
weakref（PHP ≥ 7.4）包装，但注意WeakReference::create($pdo)后，闭包内需主动$wr->get()并判空——它不阻止GC，只是提供访问通道
容易被忽略的间接引用链
闭包未必直接use $pdo，但可能通过中间对象间接持有。典型路径：
-
$logger->info('query', ['pdo' => $pdo])→ 日志上下文数组保存了对象引用 -
$cache->set('key', $pdo, 300)→ 缓存驱动（如 APCu）序列化失败时会 fallback 到引用存储 -
new class($pdo) extends SomeHandler {}→ 匿名类构造函数接收并赋值给$this->pdo，形成隐式强引用
真正难排查的不是闭包本身，而是谁把那个闭包存进了静态数组、全局事件总线或单例容器里——一旦注册，它就活到请求结束甚至更久。务必检查所有EventDispatcher::addListener()、Container::bind()、static::$handlers[] = $closure这类操作。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
