PHP析构函数__destruct()不接受参数、不可手动调用、执行时机不可控；其触发依赖引用计数归零，循环引用在PHP 7.4+已改善但旧环境仍存风险；异常终止（如exit）或输出缓冲导致日志丢失；资源释放须加防御判断，优先主动关闭而非依赖析构。
PHP析构函数不是靠“学”出来的，是靠“踩坑”和“验证调用时机”建立直觉的。 它不接受参数、不能手动调用、执行顺序不可控——指望它做关键逻辑等于埋雷。真正该花时间搞懂的，是它在什么情况下根本不会触发，以及为什么 fclose() 放在 __destruct() 里有时没效果。
什么时候 __destruct() 根本不执行
最常被忽略的是引用计数机制：对象只有在所有变量引用都被清除后，才会进入销毁队列。只要还有一个变量指向它，unset() 某个变量毫无意义。
-
$a = new FileHandler(); $b = $a;→ 此时unset($a)不会触发__destruct() -
$b = null;或脚本结束时，才真正销毁对象 - 循环引用（如对象 A 持有 B，B 又持有 A）在 PHP 7.4+ 已基本解决，但旧代码或扩展中仍可能卡住 GC
- CLI 模式下脚本异常终止（如
exit()、信号中断），__destruct()可能跳过
为什么 __destruct() 里写日志经常看不到输出
因为脚本结束前输出缓冲区可能已被清空，或 SAPI 层（如 Apache、FPM）已关闭标准输出流。不是函数没运行，是输出被吞了。
- 调试时优先用
error_log("msg")，而不是echo或print - 避免在
__destruct()中依赖$_SERVER、$_GET等超全局变量——它们可能已被重置 - FPM 下若启用了
catch_workers_output = yes，echo才可能落到 error log，但不可靠
__destruct() 能不能关数据库连接或释放锁
可以，但必须加防御性判断，且不能假设它“一定来得及”。比如 PDO 连接在脚本结束时自动 close，__destruct() 里再 close 属于冗余；而 Redis 锁若没设过期时间，靠 __destruct() 释放就极危险。
立即学习“PHP免费学习笔记（深入）”；
- 文件句柄类操作（
fopen/fclose）适合放进去，因资源有限且无自动回收 - 网络连接（cURL handle、Socket）建议显式
curl_close()，别等__destruct() - 若用
__destruct()清临时文件，务必检查file_exists()和is_writable()，防止脚本重启时重复清理失败
真正难的不是写 __destruct()，而是判断“这个资源，到底该由谁负责关”。多数时候，主动释放比被动等待更可靠；而一旦选了被动方式，就得接受它可能不来、可能晚来、可能来的时候环境已残缺。
