__destruct()在对象被垃圾回收判定为不可达时自动调用，非unset()后立即执行，也非脚本结束瞬间统一触发；常见于脚本终止前逆序销毁、作用域退出且无引用、或PHP 7.4+正确处理的循环引用场景。
析构方法什么时候被调用
PHP 的 __destruct() 方法在对象真正“消失”时自动触发，不是你写完 unset() 就立刻执行，也不是脚本一结束就统一收尾——它取决于 PHP 的垃圾回收（GC）机制是否判定该对象已不可达。
常见触发场景：
- 脚本执行结束前，所有未被引用的对象按“后创建、先销毁”的顺序调用
__destruct()（栈式逆序） -
unset($obj)后，若该对象再无其他变量或数组元素指向它，GC 可能在下一次循环中立即回收并调用析构 - 函数内创建的对象，在函数返回后作用域销毁，若无外部引用，也会触发析构
- 循环引用（如 A→B 且 B→A）在 PHP 7.4+ 中可被 GC 正确识别并清理，但旧版本可能延迟甚至漏掉析构
为什么不能给 __destruct() 加参数
因为 PHP 引擎调用它时根本不知道传什么——这不是你手动调用的普通方法，而是生命周期终点的被动通知。加参数不仅语法报错 Parse error: syntax error，更违背设计意图：析构只负责“善后”，不接收新输入。
如果你需要传递上下文（比如关闭哪个数据库连接），得靠对象自身的属性提前存好：
立即学习“PHP免费学习笔记（深入）”；
class DatabaseConnection {
private $host;
private $resource;
public function __construct($host) {
$this->host = $host;
$this->resource = mysqli_connect($host);
}
public function __destruct() {
if ($this->resource) {
mysqli_close($this->resource); // 用 $this->host 做日志也行
error_log("Closed connection to {$this->host}");
}
}
}
容易踩的坑：析构里做耗时或失败敏感操作
析构方法运行在“脚本收尾阶段”，此时输出缓冲可能已关闭、HTTP 响应头已发送、数据库连接可能已断开，甚至错误处理机制（如 set_error_handler）都未必有效。
典型翻车点：
- 在
__destruct()里执行file_put_contents()写日志 → 权限不足或磁盘满时静默失败，无从排查 - 调用
curl_exec()上报状态 → 网络超时、DNS 失败，阻塞整个脚本退出 - 依赖
$this->someProperty，但该属性在unset()前已被设为null或重置 → 访问空对象报 Notice - 在析构中抛出异常 → PHP 会直接致命错误
Fatal error: Uncaught Exception，且无法被 try/catch 捕获
替代方案比硬扛析构更可靠
如果清理逻辑重要、需可控、要反馈，别押宝 __destruct()。主动管理才是正解：
- 提供明确的
close()或shutdown()方法，文档写清“必须调用”，配合 IDE 提示或静态分析工具标记未调用 - 用
register_shutdown_function()做兜底，但它不绑定对象，需自行维护资源引用表 - 对关键资源（如临时文件、锁），用
atexit-风格注册清理回调，比依赖对象生命周期更稳 - PHP 8.1+ 支持
WeakMap，可辅助跟踪活跃对象，但别用它替代显式释放
最常被忽略的一点：析构不是保险丝，它是最后一声叹息。指望它兜住所有问题，等于把房门钥匙焊死在门上，还指望有人帮你捡回来。
