frankenphp常驻模式下rss持续上升是因gc缓冲区滞留循环引用对象，需手动调用gc_collect_cycles()和gc_mem_caches()，并用memory_get_peak_usage(true)监控，避免静态属性、闭包捕获及全局变量导致的隐式内存泄漏。
FrankenPHP里memory_get_usage()没涨但RSS持续上升
这是 FrankenPHP 常驻模式下最典型的“假稳定、真泄漏”现象。因为 memory_get_usage() 只统计 PHP 堆内当前活跃 zval，而循环引用对象虽已逻辑死亡（无外部可达路径），却因 refcount 未归零卡在 GC 缓冲区，RSS（实际进程内存）仍被 OS 持有。尤其在协程密集场景，gc_collect_cycles() 不会自动触发，必须手动干预。
- 每轮 HTTP 请求或后台任务结束时，显式调用
gc_collect_cycles()和gc_mem_caches() - 用
memory_get_peak_usage(true)替代memory_get_usage()打点——它包含已被 GC 标记但尚未归还 OS 的内存块 - 检查是否在路由闭包、中间件或事件监听器中用了
use ($this)或use (&$bigArray)，这类捕获会隐式延长对象生命周期 - 若使用了
WeakMap存储上下文，请确认键是对象实例本身（而非 ID 字符串），否则无法触发弱引用自动清理
用 WeakReference 快速验证谁在强持对象
当你怀疑某个服务类或连接管理器被意外钉住，不要靠猜，直接上 WeakReference 监控。它不阻止 GC，但能告诉你“理论上该释放的对象，是否还有人强引用着”。
- 在对象创建后立即包裹：
$weakRef = WeakReference::create($serviceInstance) - 业务逻辑执行完毕后（如请求返回前），检查
$weakRef->get() !== null；若为true，说明存在至少一个强引用未断开 - 配合
debug_zval_dump($serviceInstance)查看refcount__gc和is_ref__gc：若前者 >1 且后者为1，基本可锁定是静态属性、全局数组或闭包捕获导致 - 特别注意 FrankenPHP 的
app.php入口里是否定义了全局变量（如$container）并反复赋值，这会导致旧实例残留
静态属性累积 + 协程切换 = 隐形内存池
FrankenPHP 默认启用协程调度，而静态属性在协程间共享——这不是 bug，是设计使然。但如果你在中间件或控制器里往 self::$cache 不断 []= 追加数据，又没在请求结束时清空，这些数据就会跨协程、跨请求累积。
- 禁用无清理机制的静态缓存：把
static $items = [];改成每次请求新建的局部变量，或用WeakMap替代 - 若必须用静态容器，请在
onRequest或onResponse生命周期钩子里主动unset()已过期项，不要依赖“下次覆盖” - 检查是否误将协程上下文（如
Swoole\Coroutine::getuid()返回的 ID）作为键存进静态数组——协程 ID 不唯一，易造成重复插入和内存滞留 - FrankenPHP 的
php-fpm兼容模式下，$_SERVER和$GLOBALS在协程间也非完全隔离，避免往里面塞大对象
Generator/yield 是解药，不是补丁
很多 FrankenPHP 内存增长问题本质是“一次性加载全量数据再处理”，比如从数据库查 50 万行、读取 GB 级文件。用 yield 不是为了炫技，而是让内存占用从 O(N) 降到 O(1)。
- 把
foreach ($pdo->query($sql)->fetchAll() as $row)改成带yield的生成器函数，每次只 hold 一行 - 文件处理别用
file_get_contents()，改用fopen()+fgets()+yield流式读取 - 注意：生成器内部若闭包捕获了大对象（如整个 DB 连接实例），仍会泄漏——yield 本身不解决引用问题，只是降低单次峰值
- FrankenPHP 的
Http\Request对象不可序列化，别试图把它yield出去或存进静态变量，否则整个请求上下文被钉死
unset 的临时变量，叠加协程调度后会被指数级放大。最危险的不是报错，而是 RSS 悄悄爬升却不触发 Allowed memory size exhausted——等你发现时，可能已经影响到其他协程的调度延迟。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
