frankenphp 1.2 的 worker 模式不提供 pm.max_requests 配置，需在应用层手动计数并调用 frankenphp_stop_worker() 实现优雅重启，支持结合内存、线程负载等动态条件触发。
FrankenPHP 1.2 的 Worker 模式本身**不提供类似 PHP-FPM 的 pm.max_requests 配置项**，它没有内置的“每个 worker 处理 N 个请求后自动重启”机制。这个行为需要你主动设计和控制。
为什么没有 max_requests？
Worker 模式的核心是长期驻留、复用上下文（框架容器、DB 连接、OPcache 等）。FrankenPHP 默认让 worker 线程持续运行，直到进程退出或被显式终止。它把“何时重启”交还给应用逻辑，而不是硬编码一个计数器。
如何实现等效的“最大请求数”控制？
你需要在 PHP 应用层手动计数并触发优雅重启。常见做法有：
-
在中间件或全局请求钩子中累加计数器：用静态变量或
$_SERVER['frankenphp_worker_id']区分线程，记录当前 worker 已处理请求数 -
达到阈值后调用
frankenphp_stop_worker()：这是 FrankenPHP 提供的官方函数，会通知当前 worker 在完成当前请求后安全退出，由主进程拉起新 worker 接替 -
配合
max_execution_time和内存监控：例如每处理 500 个请求，检查memory_get_peak_usage()，若超限则提前调用frankenphp_stop_worker()
一个最小可行示例（Laravel 中间件）
在中间件 handle() 开头加入：
// 假设使用 static 计数（注意：多线程下需确保线程安全，实际建议用 per-worker 存储）
static $requestCount = 0;
$workerId = $_SERVER['frankenphp_worker_id'] ?? 'unknown';
$requestCount++;
if ($requestCount >= 1000) {
error_log("Worker #{$workerId} reached max requests (1000), stopping gracefully");
frankenphp_stop_worker();
}
替代方案：用外部信号或健康检查驱动
更稳健的做法不是固定请求数，而是结合运行时状态：
- 监听
/healthz或自定义指标端点，当frankenphp_busy_threads / frankenphp_total_threads > 0.95持续 1 分钟，触发部分 worker 重启 - 用
process-exporter + Prometheus监控每个 FrankenPHP 进程 RSS 内存，超过阈值（如容器 limit 的 80%）时调用frankenphp_stop_worker() - 日志中高频出现
Worker #X restarted after max_requests，说明你已在用某类封装（如 Octane 的 wrapper），此时应检查其内部配置而非 FrankenPHP 本身
本质上，FrankenPHP 把生命周期管理权交给了你——它提供停止接口，你决定何时调用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
