frankenphp 1.2 worker 模式通过 max_requests 主动重启进程实现内存可控回收，设为 500 表示每处理约 500 请求后销毁 worker 并清空所有内存资源；需结合压测与 memory_get_peak_usage 监控合理设定，禁用 0/-1，且无法解决静态变量污染等代码层问题。
FrankenPHP 1.2 在 Worker 模式下不依赖传统 FPM 的进程复用逻辑，而是采用常驻 Worker 进程 + 请求级隔离 + 显式回收兜底的内存管理模型。它的内存回收不是靠自动 GC 触发或栈清理，而是通过 max_requests 主动重启 Worker 来实现可控释放——这是当前版本最核心、最有效的内存回收调节手段。
max_requests 是核心调节参数
它不是“优化选项”，而是 FrankenPHP Worker 模式下防止内存无限增长的强制安全阀。设为 500 表示每个 Worker 处理约 500 个请求后自动退出并由主进程拉起新实例，所有 PHP 变量、OPcache 条目、未显式释放的 GD/Imagick 资源、闭包持有的容器引用、Doctrine 一级缓存等，都会随进程销毁一并清空。
怎么设才合理
- 别直接套用 500：先在压测环境加
memory_get_peak_usage(true)打点，观察每 100 个请求内存是否稳定上涨；若单次请求峰值涨 15–20MB，建议设 300 或更低 - 避免设过高（如 2000）：PHP 垃圾回收在堆 >1GB 时效率骤降，反而容易触发
Allowed memory size exhausted - 禁止设为 0 或 -1：FrankenPHP 不支持无限运行的 Worker，这等于关闭兜底机制
- 配合
memory_limit算总账：例如 16 个 Worker × 512MB = 8GB，确保宿主机有足够可用内存，且留出系统缓冲余量
它管不了的，得你手动管
max_requests 不是万能清洁工。以下问题它无法缓解，必须在代码层处理：
- 静态变量污染：
static $cache = [];在 Worker 生命周期内持续累积，重启前已影响后续所有请求 - 未关闭的资源句柄：PDO 连接没
$pdo = null或unset()，文件没fclose()，可能在重启前就耗尽Too many open files - OPcache CLI 锁死：若启用了
opcache.enable_cli=1，类定义会滞留在共享内存，Worker 重启也无效 - 日志缓冲未刷出：StreamHandler 等若没
flush()，重启可能导致最后一批日志丢失
辅助监控不能少
仅调参数不看数据，等于蒙眼开车。建议在请求末尾加入：
error_log(sprintf( '[MEM] req=%d peak=%sKB, real=%sKB', $_SERVER['REQUEST_NUM'] ?? 0, number_format(memory_get_peak_usage(true) / 1024), number_format(memory_get_usage(true) / 1024) ));
再结合 Prometheus + FrankenPHP Exporter 抓取 frankenphp_worker_requests_total 和 frankenphp_worker_memory_bytes，就能画出内存阶梯曲线，验证 max_requests 是否真正起效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
