php析构函数不会自动调用父类__destruct()，子类重写时必须显式调用parent::__destruct()以避免资源泄漏；正确做法是在子类析构末尾用method_exists检查后调用。
PHP 中调用 parent::__destruct() 不是必须的，但**在子类定义了 __destruct() 且父类析构函数有重要清理逻辑时，不调用会导致资源泄漏或行为异常**。
PHP 析构函数自动调用父类版本吗？
不调用。PHP 的析构函数 不会自动调用父类的 __destruct() —— 这和构造函数 __construct() 完全不同（后者需显式调用 parent::__construct() 才执行父类逻辑，但至少开发者普遍有意识；而析构函数容易被忽略）。
- 子类定义了
__destruct()→ 只执行子类版本，父类的__destruct()被完全跳过 - 子类没定义
__destruct()→ PHP 会自动执行父类的__destruct()（如果存在） - 多个继承层级中，每个类的
__destruct()都需手动调用parent::__destruct()才能向上链式执行
哪些场景下必须写 parent::__destruct()？
当父类的析构函数承担了不可省略的资源释放职责，而子类又重写了析构函数时，就必须补上调用。典型包括：
- 父类封装了文件句柄（
fopen()）、数据库连接（PDO实例）、cURL 句柄（curl_init()），并在__destruct()中关闭它们 - 父类注册了
register_shutdown_function()或信号处理器，需在析构中解注册 - 父类维护了静态引用计数、全局缓存键、临时文件路径列表，依赖
__destruct()清理 - 使用了 Swoole、Workerman 等常驻进程框架，对象生命周期变长，未释放的资源（如 socket、timer）会累积泄漏
不调用 parent::__destruct() 会出什么问题？
现象往往延迟暴露，调试困难：
立即学习“PHP免费学习笔记（深入）”；
-
资源泄漏：文件描述符耗尽（
Too many open files）、MySQL 连接数打满、内存持续增长 - 状态残留：临时文件未删除、锁文件未释放、Redis key 未过期，导致后续请求行为异常
- 静默失败：日志里看不到错误，但定时任务越来越慢、接口响应时间波动增大
- 析构顺序错乱：若父类析构依赖子类已释放的属性（极少见但可能），手动调用时机不当会引发 Notice 或 Warning
正确写法与注意事项
调用位置应在子类 __destruct() 末尾，确保子类自身清理完成后再交还控制权；同时建议加判空，避免父类未定义析构函数时报错：
public function __destruct()
{
// 子类自己的清理
if ($this->fileHandle) {
fclose($this->fileHandle);
}
// 安全调用父类析构（PHP 5.3+ 支持）
if (method_exists('parent', '__destruct')) {
parent::__destruct();
}
}
- PHP 5.3+ 允许在父类无
__destruct()时安全调用parent::__destruct()（不报错），但早期版本会触发 Fatal Error，所以加method_exists()更稳妥 - 不要在父类析构里访问已被子类 unset 的属性（如
$this->db），因为析构执行顺序由对象销毁时的引用关系决定，不一定按继承顺序 - 避免在
__destruct()中做耗时操作（如远程 HTTP 请求、大文件写入），它可能在脚本结束时异步触发，超时或被截断
最易被忽略的一点：IDE 和静态分析工具几乎不检查 __destruct() 的调用链，它不像 __construct() 那样有明确语法提示 —— 是否遗漏，全靠人工 review 或运行时现象反推。
