frankenphp worker 模式下 __destruct 不执行，根本原因是其采用 go 层调度的伪常驻进程模型，请求结束后强制重置运行时、跳过 php 自然析构流程，对象在 frankenphp_handle_request() 返回后即被直接回收。
FrankenPHP Worker 模式下 __destruct 不执行，根本原因在于：它**不是传统 PHP-FPM 那种“请求结束即触发 shutdown”的生命周期模型**，而是基于 Go 层调度的伪常驻进程——PHP 请求结束后，运行时环境被强制重置，对象析构逻辑被跳过。
PHP 请求边界被绕过，析构器失去触发时机
在标准 CGI/FPM 模式中，每个请求结束会调用 php_request_shutdown()，此时所有未销毁的对象才会执行 __destruct。而 FrankenPHP Worker 模式复用的是 FPM 进程池结构，但每次 HTTP 请求处理完后，它会主动清空符号表、重置全局状态、释放大部分内存（包括对象实例），并不等待 PHP 引擎自然走完析构流程。
- 对象在
frankenphp_handle_request()回调返回后就被直接回收，不进入 PHP 的常规垃圾回收阶段 - 即使你写了
unset($obj)或让对象超出作用域，也大概率不会触发__destruct - 这和 Swoole 完全不同：Swoole 的 Worker 进程长期存活，
__destruct只在对象真正被 GC 回收时才调用
Worker 脚本结构导致生命周期错位
很多开发者把传统 index.php 直接当 Worker 脚本用，里面包含框架初始化 + 请求处理 + exit，这种写法会让 FrankenPHP 在请求响应后直接终止当前执行上下文：
- 脚本里用了
exit或die，进程提前退出，析构器没机会运行 - 静态变量或单例对象跨请求残留，PHP 认为它们仍“活跃”，延迟或跳过析构
- 未将初始化逻辑（如
$app = new App()）放在while(true)循环外，导致每次请求都新建对象，旧对象被粗暴覆盖而非析构
替代方案：用显式清理代替依赖 __destruct
既然 __destruct 不可靠，就该放弃依赖它做关键清理（比如关闭连接、释放锁、写日志）。推荐以下做法：
- 在请求处理回调内，手动调用
$resource->close()或$db->disconnect() - 用
register_shutdown_function()做兜底，但它在 Worker 模式下也受限，仅适合轻量级收尾 - 对数据库连接等资源，优先使用连接池（如 Swoole 提供的
RedisPool），由池管理生命周期，而非单个对象 - 若需跨请求状态，改用 APCu、Redis 或共享内存存储，避免把状态绑在 PHP 对象上
本质上，FrankenPHP 的 Worker 模式不是为面向对象的完整生命周期设计的，它优化的是启动开销，牺牲的是 PHP 原生的请求边界语义。想稳定执行清理逻辑，就得跳出“靠析构器自动收尾”的思维惯性。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
