__destruct 并非总被调用：exit()/die()、致命错误、信号中断、sapi强制终止等场景下会跳过析构，故关键资源清理不可依赖它，须显式处理。
PHP 的 __destruct 析构函数在对象销毁时被调用，但**并非所有对象销毁都发生在脚本正常结束前**。某些边界场景下，脚本终止时析构函数根本不会执行——这不是 bug，而是 PHP 生命周期与资源管理机制决定的。
脚本被 exit() 或 die() 强制中止
一旦调用 exit() 或 die()，PHP 立即终止执行，跳过所有待执行的析构逻辑（包括已注册的 shutdown 函数中的对象销毁）。
- 即使对象仍存在引用、尚未被 GC 收集，
__destruct也不会触发 - 常见于错误处理中：如在某个方法里检测到致命条件后直接
exit("fail")，此时当前作用域内对象的析构函数全部失效 - 替代方案：改用异常抛出 + try/catch 控制流程，确保栈展开（stack unwinding），让局部对象能正常析构
脚本因致命错误（Fatal Error）崩溃
遇到未捕获的 Fatal error（如调用不存在的方法、内存耗尽、类定义冲突等），PHP 进程会立即中止，不运行任何析构逻辑。
-
register_shutdown_function()会执行，但此时对象可能已被强制释放，__destruct不再有机会调用 - 注意：PHP 7+ 将部分致命错误转为
Error异常，可被catch，但非所有错误都可捕获（如E_PARSE、E_ERROR中的内存分配失败） - 关键点：不能依赖
__destruct做关键清理（如释放文件锁、关闭数据库连接），应在业务逻辑中显式释放
CLI 模式下信号中断（如 SIGTERM、SIGINT）
在 CLI 脚本中，若进程收到外部信号（如用户按 Ctrl+C 发送 SIGINT），默认行为是直接退出，不触发析构函数。
- 可通过
pcntl_signal()注册信号处理器，并在其中调用exit()前手动清理，但无法自动触发对象析构 - PHP 本身不保证信号到达后执行析构；GC 在进程终止时直接回收内存，跳过用户层析构流程
- 长周期 CLI 任务（如守护进程）应使用
pcntl_signal_dispatch()配合主动释放，而非等待__destruct
Web SAPI 中请求超时或客户端断连
当 PHP 运行在 Apache 或 FPM 下，若请求处理超时（max_execution_time）或客户端提前关闭连接（如 Nginx 设置了 fastcgi_read_timeout），PHP 可能被 SAPI 层强制中止。
- 此时脚本被“硬杀”，不走正常结束流程，
__destruct失效 - 尤其在 FPM 模式下，worker 进程可能被 master 杀死并重启，正在执行的请求对象不会析构
- 敏感操作（如写临时文件、更新状态标记）必须在关键节点后立即
fflush()或rename()提交，不可延迟到析构阶段
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
