FrankenPHP worker模式不内置内存阈值重启机制，依赖外部信号或进程管理器（如Supervisor/systemd）实现周期性或内存超限重启，并需在PHP层主动清理静态变量、闭包引用、SDK资源，配合Caddy metrics监控frankenphp_worker_memory_bytes趋势以触发告警重启。
FrankenPHP 的 worker 模式本身不提供类似 Laravel --memory 或 Workerman 定时打点的原生内存阈值重启机制。它的重启依赖于外部信号或进程管理策略，而非自动检测 RSS 上涨后触发。要避免内存持续上涨，关键不是“设置重启时机”，而是控制 worker 生命周期 + 主动释放资源 + 外部兜底监控。
明确 worker 退出触发方式
FrankenPHP worker 进程默认长期驻留，不会因内存增长自动退出。它只会在以下情况终止：
- 收到系统信号（如
SIGTERM），例如由 Supervisor、systemd 或手动kill发出 - PHP 应用代码中调用
exit()或发生未捕获致命错误 - FrankenPHP 主进程崩溃或被强制关闭
它不读取 --memory 参数，也不内置 RSS 监控逻辑——这点和 Laravel queue:work 或 Workerman 完全不同。
用外部进程管理器实现周期性/条件性重启
生产环境中必须借助 Supervisor 或 systemd 实现可控重启。推荐组合使用两种策略：
立即学习“PHP免费学习笔记（深入）”；
-
固定周期重启：通过
startsecs+autorestart=true配合定时脚本，例如每 2 小时supervisorctl restart frankenphp-worker -
内存超限被动重启：在 Supervisor 配置中启用
mem_limit（需 cgroup v2 支持）或使用killasgroup=true+ 外部监控脚本定期检查ps aux --sort=-%mem | head -1，发现 RSS 超过阈值（如 512MB）即发信号终止
在 PHP 层主动预防内存累积
worker 常驻意味着所有静态变量、全局缓存、闭包引用、SDK 客户端实例都会跨请求存活。必须在每次请求结束前清理：
- 避免在
static $cache = []中无限制写入；改用WeakMap存储对象关联，或显式在请求末尾unset($cache[$key]) - 不要把
Request、Response或上传文件流存入静态属性——它们携带原始 body 和临时文件句柄 - HTTP/Redis/DB 客户端初始化应懒加载，并在
onWorkerStop或请求结束时调用$client->disconnect()或unset($client) - 在中间件末尾或响应发送后调用
gc_collect_cycles()，尤其处理大量数组或对象后
启用指标监控并设置告警基线
FrankenPHP 通过 Caddy 的 metrics 暴露 frankenphp_worker_memory_bytes 等指标（需开启 admin 端口）：
- 配置 Prometheus 抓取
http://localhost:2019/metrics - 监控
frankenphp_worker_memory_bytes{worker="app"}是否随时间线性上升 - 当 10 分钟内增长超过 100MB，触发告警并自动执行
supervisorctl restart
这比依赖单次 memory_get_usage() 更可靠，因为它反映的是真实 RSS 变化趋势。
