FrankenPHP worker模式下N+1问题更易暴露，因PDO连接复用与Eloquent查询缓存跨请求生效，导致同一worker内重复执行低效SQL、Threads_running爬升、慢日志集中爆发；而传统PHP-FPM每次请求进程重置，问题被掩盖为偶发抖动。
不会更明显，反而更容易暴露和缓解——关键在 worker 模式下「数据库连接复用」和「Eloquent 查询缓存失效」的叠加效应。
为什么 N+1 在 FrankenPHP worker 模式下容易被误判为“更严重”
传统 PHP-FPM 每次请求都是全新进程，PDO 连接自动关闭、Eloquent 查询缓存（如 remember()）也随进程销毁而清空。N+1 问题虽然存在，但每次都是“干净”的起点，监控指标（比如慢查询数）相对平稳，不容易触发告警阈值。
而 FrankenPHP 的 worker 模式让 Laravel 应用常驻内存：PDO 连接默认复用、模型状态持续存在、Cache::remember() 或 Model::remember() 的缓存可能跨请求生效——这本是好事，但一旦代码里有未预期内的 N+1（比如循环中调用 $user->posts 却没加 with('posts')），它会在同一个 worker 生命周期内反复执行相同低效 SQL，且连接不释放，导致：
- 同一 worker 处理连续请求时，MySQL 的
Threads_running可能缓慢爬升 - 慢日志里出现大量重复的关联查询，时间戳却集中在几秒内
- OPcache 编译后的字节码不变，但实际执行路径因对象状态残留而变长
Laravel 项目在 FrankenPHP 上必须检查的三个地方
不是 FrankenPHP 引发了 N+1，而是它让原有隐患从“偶发抖动”变成了“稳定可复现”。迁移后要立刻验证：
立即学习“PHP免费学习笔记（深入）”；
-
DB::enableQueryLog()+ 请求后 dumpDB::getQueryLog()，确认是否真有 N+1（别只信 Telescope 的采样） - 检查
config/database.php中'persistent' => true是否被意外开启——worker 模式下持久连接需配合连接池或显式DB::reconnect() - 禁用 Eloquent 的全局查询缓存（如
Model::preventLazyLoading()开发环境强制报错，或生产启用APP_DEBUG=false时仍保留DB::listen()监听未预加载关系）
经典模式 vs worker 模式对 N+1 的实际影响
经典模式（frankenphp php-server）和传统 FPM 行为几乎一致：每个请求启动新 Laravel 实例，N+1 表现和原来一样，只是启动更快、延迟更低；worker 模式（frankenphp worker）才真正改变游戏规则：
- 经典模式：N+1 是“单次请求内的性能浪费”，修复优先级中等
- worker 模式：N+1 是“worker 生命周期内的资源泄漏”，可能导致连接耗尽、OOM、响应时间阶梯式上升
- 注意：Laravel Octane 的
--max-requests=500参数不能替代代码修复——它只是让 worker 主动退出，把问题掩盖成“偶发 502”
最常被忽略的一点：FrankenPHP 自带的 frankenphp php-cli 命令执行 Artisan 命令时仍是短生命周期，和 worker 模式无关。所以 php artisan tinker 里测出来的 N+1 行为，和线上 worker 的表现可能完全不同。
