FrankenPHP 通过 max_requests 强制 worker 轮转（如 --max-requests=300）并配合 memory_limit 限制（如384M）、主动 GC 和静态变量清理，双管齐下控制第三方库内存泄漏影响。
FrankenPHP 本身不拦截或重写第三方库的内存行为，所谓“临时缓解”不是打补丁，而是用进程级兜底 + 请求级干预双管齐下，把泄漏影响控制在可接受窗口内。
用 max_requests 强制 worker 进程轮转
这是最直接有效的临时手段。第三方库泄漏通常呈线性累积，500 次请求后内存可能涨到 400MB+，再跑下去就 OOM。设置轮转能确保进程在失控前退出：
-
frankenphp worker --max-requests=300（比预估泄漏阈值低 30%） - 配合 systemd 的
Restart=always和StartLimitIntervalSec=60，避免重启风暴 - 注意：该参数只对
worker模式生效，serve模式不支持
在请求末尾主动触发 GC 并清空可疑静态缓存
很多第三方库（如旧版 Guzzle、Monolog 扩展、自定义 SDK）会把连接池、日志缓冲、解析器状态存在 static 属性里。你无法改它源码，但可以在每次请求结束时干预：
- 在 Symfony 的
kernel.terminate事件里加：gc_collect_cycles()+unset($GLOBALS['third_party_cache']) - 检查
var_dump(array_keys($GLOBALS))，揪出命名不规范的全局变量（比如$guzzle_pool、$sdk_client） - 对已知泄漏大户（如某些 XML 解析器），在 controller 结尾手动调用其
reset()或destroy()方法（查它的 public API）
限制单个请求可用内存，不让泄漏拖垮整个进程
不要依赖 memory_limit = -1 或设得过大。泄漏库往往在某个临界点后突然崩坏（比如缓存哈希表 rehash 失败），提前掐断更稳妥：
立即学习“PHP免费学习笔记（深入）”；
- 在入口文件顶部加：
ini_set('memory_limit', '384M');（比容器mem_limit少 20%） - 若用 Docker，确保
mem_limit: 512m且memory_limit≤ 400M，留出内核和 FrankenPHP 自身开销 - 避免在 CLI 环境下设
-1—— PHP 垃圾回收在 >1GB 堆上会明显变慢，反而加剧泄漏感知
真正难处理的不是泄漏本身，而是泄漏发生在 preload 阶段或扩展层（如某些 C 扩展未实现 MSHUTDOWN 钩子）。这种情况下，max_requests 是唯一可靠防线，其他操作只是减缓恶化速度。
