unset后memory_get_usage()不降是正常现象，因unset仅断开变量绑定，内存是否释放取决于引用计数、gc状态及内存池复用，frankenphp完全复用php核心内存管理逻辑。
unset 后 memory_get_usage() 不降是正常现象
PHP（包括 FrankenPHP）的 unset() 从不承诺“立刻降低 memory_get_usage() 的返回值”。它只做一件事：断开变量名和其背后 zval 的绑定。内存是否归还给 Zend 内存管理器（甚至是否交还给操作系统），由引用计数、GC 状态、内存池复用策略共同决定。FrankenPHP 作为 SAPI 层，完全复用 PHP 核心的内存管理逻辑，没有额外干预能力。
FrankenPHP 下 unset 失效的常见真实原因
在 FrankenPHP 的长生命周期请求（如 HTTP/2 流、SSE、协程处理）中，变量残留更隐蔽，容易误判：
-
$list = Db::select()返回的Collection对象被中间件、日志钩子或事件监听器悄悄持有（例如通过think\facade\Event::listen()注册了闭包捕获了 $list）——unset($list)只清局部引用，根引用还在 - 使用
&$item遍历大数组时，PHP 7.4+ 会隐式增加引用计数；循环结束后unset($item)无效，因为 foreach 内部临时变量未真正脱离作用域 - 对象属性里存了资源句柄（如
$this->curl）、PDOStatement 或未关闭的文件流——unset($obj)不会自动释放这些底层资源，必须显式调用curl_close()、$stmt->closeCursor()等 - FrankenPHP 的 Worker 模式下，脚本可能复用同一进程处理多个请求；若变量定义在全局作用域或静态属性中（如
static $cache = []），unset()在单次请求内无效
怎么确认是不是真没释放？别只看 memory_get_usage()
单靠 memory_get_usage() 容易误导。它反映的是当前分配给 PHP 的内存块总量，不是“正在被业务代码使用的量”：
- 用
memory_get_peak_usage(true)查真实峰值（real usage），排除内存池缓存干扰 - 在关键清理点后加
gc_collect_cycles()——但仅一次，别放循环里（FrankenPHP 下频繁调用反而拖慢协程调度） - 检查是否存在循环引用：
var_dump(xdebug_debug_zval('your_var'))看refcount和is_ref；若refcount > 1，说明还有其他变量或对象在 hold 它 - 对 Query/Collection 对象，优先用
Db::table(...)->chunk(100, function ($items) { ... })替代全量select()，避免一次性加载全部模型实例
FrankenPHP 特定场景下的稳妥清理姿势
FrankenPHP 的协程和 Worker 模型放大了传统 PHP 中被忽略的生命周期问题：
- 在
__destruct()或请求结束回调（如FrankenPHP\on_request_end()）中清理：确保$this->bigData = null、$this->pdo = null，而不是依赖作用域自然退出 - 避免在协程函数里用
global或static持有大对象；改用context传递或明确生命周期边界 - 导出类任务中，每处理完一批（如 50 条），执行：
unset($batch); $batch = [];—— 先unset再赋空数组，双重切断引用链 - 确认
zend.enable_gc = 1（PHP 8.1+ 默认开启），但不要幻想 GC 是“自动内存清道夫”；它只扫已断开引用的循环结构，不扫还活着的长引用
unset()，而是没找到那个躲在日志、事件、中间件或静态属性里的“最后一个引用”。FrankenPHP 让这个问题更难察觉，因为它让请求上下文活得更久。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
