__destruct 在对象引用计数降为0且php决定回收时触发，并非离开作用域立即执行，不可依赖其时机做关键操作，也不可捕获异常，适合轻量资源清理但需避免阻塞i/o。
__destruct 方法在对象销毁时触发，但不是“离开作用域就立刻调用”
PHP 的 __destruct 不是 JavaScript 的 finally，也不是 C++ 的析构函数那样精准可控。它只在对象被销毁（reference count 降为 0）且 PHP 内存管理决定回收该对象时才执行 —— 这个时机可能比你预期的晚，甚至延迟到脚本结束。
- 常见错误现象：
__destruct没有按预期顺序执行，比如在unset($obj)后没立刻看到日志输出；或在 CLI 脚本里，所有__destruct都堆在最后统一触发 - 使用场景：适合做资源清理（如关闭文件句柄、释放 cURL 句柄），但**不能依赖它做关键状态同步或事务提交**
- 参数差异：该方法不接受任何参数，定义写成
function __destruct()就行，加参数会报Warning: Declaration of ... should be compatible with ... - 性能影响：频繁创建/销毁对象时，
__destruct本身开销不大，但如果里面做了阻塞 I/O（如写文件、发 HTTP 请求），会拖慢整个请求生命周期
CLI 和 Web SAPI 下的销毁时机差异很大
Web 环境（如 Apache + mod_php 或 FPM）中，一次请求结束后 PHP 会清空所有变量并批量调用 __destruct；而 CLI 模式下，只要引用还存在（哪怕只是全局数组里存着一个对象），就不会销毁。
- 常见错误现象：CLI 脚本里把对象存进
$GLOBALS['cache'][]，结果__destruct死活不触发；或者在循环中 new 对象但没 unset，内存持续上涨 - 使用场景：CLI 工具中若需及时释放资源，建议显式调用
unset($obj)或设为null，而不是等脚本自然退出 - 兼容性影响：PHP 8.1+ 引入了
__serialize/__unserialize，但__destruct行为未变；不过在启用 OPcache 时，某些极端情况下的销毁顺序可能更不可预测
__destruct 无法捕获异常，也不能阻止脚本终止
在 __destruct 中抛出的异常会被静默忽略，不会中断执行，也不会出现在错误日志里（除非启用了 log_errors = On 并设置了 error_log），这点和 __construct 完全不同。
- 常见错误现象：在
__destruct里写了throw new Exception(...)，结果什么都没发生，连try/catch都包不住 - 使用场景：必须做失败兜底时，改用
error_log()记录，或写入临时文件；涉及数据库操作，优先用事务 + 显式 commit/rollback，别指望__destruct回滚 - 参数差异：不要试图在
__destruct里访问$this->property以外的动态上下文，因为此时对象已处于销毁阶段，部分属性可能已被释放（尤其含闭包或资源类型的属性）
替代方案比死磕 __destruct 更可靠
如果业务逻辑真正需要“离开作用域就执行某事”，__destruct 是最弱的选择。PHP 7.4+ 的 weakref 扩展、手动注册 shutdown 函数、或用 RAII 风格封装（如 using() 类辅助函数），都比依赖它稳定。
立即学习“PHP免费学习笔记（深入）”；
- 常见错误现象：为了“确保日志写入”，在
__destruct里 fopen/fwrite，结果因并发或权限问题失败，又没任何反馈路径 - 使用场景：日志类建议提供
flush()方法，并在关键位置显式调用；连接池类应实现close()并由上层控制生命周期 - 性能影响：用
register_shutdown_function()替代__destruct做兜底清理时，注意它会在所有对象销毁后执行，顺序更不可控，但至少能 catch 异常
__destruct 最容易被当成“安全网”去用，但它连网眼都漏风。真要靠得住的操作，得从设计上让资源生命周期可预测、可追踪。 
