FrankenPHP图片处理内存暴涨主因是GD/Imagick资源未显式释放：GD需每次调用imagedestroy()，Imagick需clear()+destroy()并禁用缓存；须确认worker模式、限制单次内存与超时、销毁逻辑不得依赖析构函数。
FrankenPHP 处理图片时内存暴涨，基本可以锁定是 GD 或 Imagick 扩展在常驻 worker 进程中未释放资源，叠加 PHP 的引用计数延迟回收导致的累积效应——不是单次操作写错了，而是每次 resize、crop、watermark 后残留的图像资源没被显式销毁。
确认是否真在 worker 模式下处理图片
这是所有优化的前提。如果 Caddyfile 里没写 worker，或启动用的是 frankenphp serve，那根本就不是常驻场景，内存涨了也跟 worker 无关，属于普通请求峰值问题。
- 检查 Caddyfile 中是否有
php_server { worker }块（不是php） - 启动命令必须是
frankenphp run，且日志里出现Starting PHP worker pool with X workers - 在图片处理逻辑里加
error_log('PID: ' . getmypid() . ', mem: ' . memory_get_peak_usage(true));，连发 5 次相同图片请求：若 PID 不变但内存峰值持续上升，就是 worker 下的资源堆积
GD 扩展必须显式销毁图像资源
GD 的图像资源（resource 类型）不会在函数返回后自动释放，尤其在 worker 进程里，imagedestroy() 必须手动调用，否则每个请求都新增几 MB 占用。
- 所有
imagecreatefrom*（如imagecreatefromjpeg()）之后，必须配对imagedestroy($img) - 中间步骤生成的临时图也要销毁，比如先
imagecopyresampled()缩放，再加水印，缩放图和原图都要imagedestroy() - 别依赖
unset($img)—— 它只断开变量引用，不触发 GD 资源释放 - 示例片段：
$src = imagecreatefromjpeg($path); $thumb = imagecreatetruecolor(200, 200); imagecopyresampled($thumb, $src, 0, 0, 0, 0, 200, 200, imagesx($src), imagesy($src)); // ... 输出或保存 imagedestroy($thumb); // 必须 imagedestroy($src); // 必须
Imagick 扩展要禁用资源缓存并主动清空
Imagick 默认启用对象池和资源缓存，在 worker 进程里会越积越多。它不像 GD 那样靠 destroy()，而要控制实例生命周期和显式清理。
立即学习“PHP免费学习笔记（深入）”；
- 避免全局复用同一个
Imagick实例；每次处理新建，用完立刻$imagick->clear(); $imagick->destroy(); - 在
php.ini中关闭缓存：imagick.skip_version_check=1和imagick.progress_monitor=0（后者防监控句柄泄漏） - 关键配置项：
imagick.set_single_thread=1（避免多线程下资源竞争导致的隐性泄漏） - 如果用了
Imagick::readImageBlob()，务必配合Imagick::setImageFormat()显式指定格式，否则内部可能缓存冗余解码器
统一兜底：限制单次图片处理的内存与超时
即使代码写对了，异常输入（如 100MB TIFF）仍可能瞬间打爆 worker。FrankenPHP 层必须设硬边界。
- Caddyfile 中为图片路由单独设
max_requests 50（比通用值更激进），防止一个坏图拖垮整个 worker - 在处理前强制限流：
ini_set('memory_limit', '128M');—— 注意：这行必须放在public/index.php入口或控制器开头，worker 启动后仍可生效（不同于php.ini的全局限制） - 用
set_time_limit(30)防止大图解码卡死；搭配libpng等底层库的 timeout 参数（如 Imagick 的setImageDelay()不相关，别误用） - 记录峰值：
error_log(sprintf('Image %s: peak %d KB', $filename, memory_get_peak_usage(true) / 1024));，压测时看是否阶梯上升
最易被忽略的一点：图片处理逻辑若嵌套在 Symfony EventListener 或 Twig Extension 里，容易被当成“一次请求内自动清理”，其实 worker 下这些对象长期存活，__destruct() 根本不会触发。所有图像资源销毁动作，必须写在业务方法体内，不能靠析构函数兜底。
