__destruct在对象引用计数归零时调用，而非离开作用域立即执行；它不保证运行（如exit、致命错误时失效），不可依赖其做关键资源清理，仅作“尽力而为”的补救。
PHP中__destruct什么时候被调用？
__destruct不是“对象一离开作用域就立刻执行”，它只在对象**引用计数归零**时触发——也就是没有任何变量、属性或全局容器还持有该对象的引用。常见误判场景包括：
• 在函数内unset($obj)，但该对象同时被数组或静态属性引用着
• 使用gc_collect_cycles()前，循环引用对象可能长期不销毁
• CLI脚本结束前，PHP会统一清理，此时__destruct才集中执行，顺序不可控
释放资源必须检查资源是否真实存在
直接在__destruct里fclose($this->handle)或mysqli_close($this->conn)很危险：构造失败、提前关闭、或资源已被__destruct多次调用（比如手动unset后又因GC再触发）都会导致警告甚至崩溃。
实操建议：
- 在类属性中用
bool $isClosed标记资源状态，__destruct开头先if ($this->isClosed) return; - 使用
is_resource($this->handle)或$this->conn instanceof mysqli做类型兜底 - 避免在
__destruct中抛出异常——PHP 7+ 会静默忽略，且可能中断后续析构链
不能依赖__destruct做关键清理
以下情况__destruct根本不会运行：
• 脚本被exit()或die()强制终止
• 发生致命错误（如Fatal error: Allowed memory size exhausted）
• Apache模块模式下进程复用，对象可能跨请求残留
• CLI中信号中断（如SIGTERM）
所以对数据库连接、文件锁、临时文件这类关键资源，必须：
• 提供显式close()或destroy()方法，并文档强调“必须调用”
• 在__destruct里只做“尽力而为”的补救，比如if ($this->tmpFile && file_exists($this->tmpFile)) unlink($this->tmpFile);
• 不在__destruct中执行耗时操作（如HTTP请求、大文件写入），它没有超时控制，可能卡住整个请求结束
立即学习“PHP免费学习笔记（深入）”；
多对象循环引用时__destruct可能永不触发
比如A对象持有了B的引用，B又通过回调闭包捕获了A，形成闭环。PHP 5.3+ 的GC能回收部分循环引用，但并非100%可靠，尤其含资源句柄时。
验证方法：
• 在__construct和__destruct里加echo "A: construct/destruct";观察输出
• 运行gc_collect_cycles()后检查memory_get_usage()是否回落
• 更稳妥的做法是主动打破引用：在业务逻辑结束处$a->b = null; $b->a = null;，而不是等GC
__destruct”，而是判断“这个资源到底有没有被其他地方悄悄续命”。别让它背关键责任。 
