__destruct 在引用计数归零或脚本结束时才可能触发，不保证执行，不可用于关键资源清理；必须提供显式关闭方法，并在 __destruct 中仅做轻量兜底。
__destruct 不是“对象一离开作用域就执行”，它只在引用计数归零时触发，且不保证一定运行——关键资源清理绝不能只靠它。
__destruct 什么时候真正被调用
它不是作用域退出的钩子，而是 PHP 引用计数器降到 0 的瞬间（或脚本结束时统一回收）才可能触发。常见误判场景：
-
unset($obj)后没输出？可能该对象还被数组、静态属性、闭包或全局变量引用着 - CLI 脚本里
echo没看到析构日志？因为 PHP 通常在脚本彻底退出前才集中调用，顺序不可控 - Web 请求中
__destruct里写文件没生效？Apache/FPM 进程复用下，对象可能跨请求残留，根本不会销毁 - 循环引用（比如 A→B 且 B 的闭包捕获了 A）时，即使 PHP 7.4+ GC 增强，含资源句柄的对象仍可能永不触发
__destruct
为什么 fclose() 或 mysqli_close() 直接写在 __destruct 里很危险
资源可能早已关闭、构造失败未初始化、或 __destruct 被重复调用（如手动 unset 后又遇 GC）。直接操作会报 Warning: mysqli_close(): Couldn't fetch mysqli 或静默失败。
- 务必先检查资源有效性：
is_resource($this->handle)或$this->conn instanceof mysqli - 加状态标记：
private $isClosed = false;，__destruct开头加if ($this->isClosed) return; - 避免在
__destruct中抛异常——PHP 7+ 会忽略，还可能中断后续对象的析构链
哪些情况 __destruct 根本不会执行
依赖它做关键清理等于埋雷：
-
exit()或die()立即终止脚本 - 发生致命错误（如
Fatal error: Allowed memory size exhausted） - 信号中断（CLI 下收到
SIGTERM） - Web SAPI 中因超时、客户端断连被强制 kill
所以对数据库连接、临时文件、锁文件等，必须提供显式 close() / destroy() 方法，并在文档和注释里强调「必须手动调用」；__destruct 只保留最轻量的兜底：比如 if ($this->tmpFile && file_exists($this->tmpFile)) unlink($this->tmpFile);。
验证 __destruct 是否按预期工作
别只靠眼见为实，得看引用和 GC 行为：
- 在
__construct和__destruct里加echo "A: construct/destruct\n";，配合ob_flush(); flush();观察输出时机 - 手动触发 GC：
gc_collect_cycles();后查memory_get_usage(true)是否回落 - 更可靠的做法是主动解引用：业务逻辑结束前写
$a->b = null; $b->a = null;，而不是赌 GC
真正难处理的从来不是“怎么写 __destruct”，而是搞清“它到底会不会跑、什么时候跑、跑几次”。把清理逻辑塞进这里，就像把房门钥匙交给快递员——他可能迟到、失联，甚至根本没收到。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
