应限制 Symfony 长时间运行进程的生命周期并主动释放资源：设置超时重启、循环内清空 Stopwatch 和输出缓冲、禁用非必要回调、避免闭包/静态引用滞留内存，紧盯 peak_usage。
长时间运行的 Symfony 进程（比如队列消费者、WebSocket 服务、定时任务）如果不主动干预，memory_get_usage() 会持续上涨，最终触发 Fatal error: Allowed memory size exhausted。根本原因不是 Symfony 本身泄漏，而是 PHP 的引用计数机制 + 未释放的闭包/事件监听器/缓存引用导致对象无法被 GC 回收。
用 Process::setTimeout() 和重启策略替代“一直跑”
别让单个 Process 实例无限期运行。即使逻辑上是“常驻”，也应设计成有限生命周期：
- 设置明确超时：
$process->setTimeout(300)（5 分钟），超时后由父进程捕获异常并重启子进程 - 在子进程内部主动退出：每处理 N 条消息或运行 T 秒后调用
exit(0)，由 supervisord / systemd / 或自定义守护脚本拉起新实例 - 避免在循环中累积构建大型数组或未清理的
Stopwatch事件 —— 每次循环结束前调用$stopwatch->reset()
禁用 Process 的完整输出缓冲，改用实时流读取
默认 $process->run() 会把全部 stdout 和 stderr 缓存在内存里，大日志或 dump 输出直接撑爆内存：
- 改用
$process->start()+$process->getIncrementalOutput()或$process->getIncrementalErrorOutput()边读边处理 - 确保每次读取后清空缓冲：
$process->clearOutput(); $process->clearErrorOutput(); - 若需过滤日志，不要用
str_replace()处理整段输出，而是在增量读取时逐行判断并丢弃无关内容
关闭 Process 内部的非必要回调和引用
Symfony Process 在内部使用匿名函数绑定 $this，形成隐式循环引用，阻碍 GC：
- 显式禁用输出回调：
$process->disableOutput()（如果不需要捕获输出） - 不使用
setCallback()，改用外部轮询 + 增量读取；若必须用，确保回调内不捕获$this或大对象 - 执行完后手动切断引用：
unset($process);，尤其在长循环中 - 检查是否误将
Process实例存入静态属性或全局数组 —— 这是最隐蔽的内存滞留点
真正难处理的从来不是“怎么释放”，而是“哪些引用你根本没意识到还活着”。一个 use ($logger, $config) 的闭包、一次忘记 unset() 的临时结果数组、甚至 Doctrine EntityManager 中未 clear() 的实体，都可能让几十 MB 内存永远卡在那儿。盯住 memory_get_peak_usage() 而不是当前值，它才暴露真实压力点。
