FrankenPHP Worker 内存泄漏主因是对象被静态属性、闭包或SDK全局回调强引用钉住，GC无法触发回收；需监控RSS、限制max_requests并避免静态缓存。
FrankenPHP Worker 模式下内存只涨不降，不是 PHP-FPM 那种“每次请求重加载框架”的堆膨胀，而是常驻进程里对象被强引用钉住——memory_get_usage() 可能稳定，但 ps aux 看到的 RSS 会线性爬升。根本原因不是 GC 失效，是 GC 根本收不到回收信号。
为什么 gc_collect_cycles() 基本没用
Worker 进程启动后，PHP 的 GC 默认开启，但它的触发条件是“疑似循环引用对象数达到阈值”。而 FrankenPHP 的典型泄漏场景里，对象没形成传统循环引用，而是被以下三类东西稳稳钉住：
-
static属性或全局数组持续追加（如self::$cache[] = $request），键值未清理，对象生命周期 = 进程寿命 - 闭包隐式捕获
$request或$response实例——它们自带原始 body、上传文件、解析后的 JSON 等大块内存，且闭包本身又被定时器、事件监听器或中间件长期持有 - 第三方 SDK（如 EasyWeChat、阿里云 OSS）在构造时注册了全局回调或内部定时器，
__destruct()不保证执行，close()被忽略
FrankenPHP 特有的泄漏高发点
它把 PHP 运行时嵌进 Caddy 进程，意味着所有 Worker 共享同一个 Go runtime 上下文，某些底层资源释放路径和纯 PHP-FPM 不同：
- HTTP 客户端（如
curl_init()或 Guzzle）未显式curl_close()，Go 层可能缓存连接句柄，PHP 层unset()不触发底层释放 - 使用
stream_socket_client()建立长连接后，未在onClose或请求结束时fclose()，socket 文件描述符和缓冲区持续累积 - 自定义 Caddy 插件或 FrankenPHP 扩展中调用了
gc_disable()（极少见但存在），导致整个 Worker 的 GC 被静默关闭 - 在
Caddyfile中配置了php_worker但未设max_requests，单个 Worker 处理百万请求后，静态缓存、ORM 查询结果、日志缓冲全堆在内存里
怎么确认是不是 FrankenPHP Worker 真泄漏
别只看 memory_get_usage()，盯紧操作系统级指标：
立即学习“PHP免费学习笔记（深入）”；
- 用
ps aux --sort=-%mem | head -5找出 RSS 最高的 FrankenPHP Worker 进程 PID - 对该 PID 执行
cat /proc/<pid>/status | grep VmRSS</pid>，记录初始值；压测同一接口 1 万次后再次查看，若增长 >20MB 且gc_collect_cycles()后无回落，就是真泄漏 - 在 Worker 启动后、每个请求处理末尾加
echo memory_get_peak_usage(true), "\n";，观察该值是否随请求数线性上升（比如每千次 +8KB） - 检查
frankenphp.log是否有Allowed memory size exhausted或worker exited with code 137（OOM killer 杀掉）
临时缓解与根治方向
FrankenPHP Worker 的泄漏修复逻辑和 RoadRunner/Workerman 一致，但要额外注意 Go 层交互边界：
- 禁用所有
static数组缓存，改用 Redis 或WeakMap（PHP 8.0+）；若必须本地缓存，加长度限制：count($cache) > 500 && array_shift($cache) - 闭包里只传 ID、IP、时间戳等标量，绝不用
use ($request)；定时器回调优先写成function () { ... }独立函数 - 所有 SDK 初始化延迟到首次使用，断连后显式调用
$sdk->close()并unset($sdk)；对 Guzzle，设置http_errors => false和timeout防止连接挂起 - 在
Caddyfile中强制重启策略：php_worker max_requests 5000，让 Worker 在内存失控前优雅退出
最易被忽略的是：FrankenPHP 的 Worker 进程一旦启动，其 PHP 扩展加载状态、全局常量、opcache 编译结果全部固化——哪怕你改了代码，不重启 Worker 就不会生效。内存泄漏往往藏在你以为“已经修好”的旧代码里。
