webman内存不会自动归零，因worker进程常驻，unset()仅断开变量名与zval绑定，不释放仍被静态属性、闭包或循环引用持有的zval；必须手动清理大变量、限制静态缓存、适时调用gc_collect_cycles()并监控refcount。
Webman 内存不会自动归零，靠 unset() 或等请求结束根本不管用——Worker 进程常驻，所有未切断的引用都会持续累积。
为什么 unset($bigArray) 后 memory_get_usage() 没变化
因为 unset() 只是断开变量名与 zval 的绑定，不保证 zval 立即释放。常见原因有：
- 该数组还被其他变量、静态属性（如
static::$cache）、闭包use捕获着，refcount > 0 - 数组内部存在循环引用（比如嵌套对象互相持有时），PHP 引用计数机制失效，必须 GC 扫描才能识别
- zval 被 interned string、全局符号表或 opcache 缓存间接持有（尤其在 CLI/常驻进程中更顽固）
验证方式：调用 xdebug_debug_zval('bigArray') 查 refcount；或 gc_status() 看 roots 是否长期非零。
Webman 中必须手动清理的三类变量
传统 PHP-FPM 下“请求结束即重置”的假象，在 Webman 里完全不存在。以下变量若不显式干预，会跨请求驻留：
-
$request或$response实例被闭包捕获（例如定时器回调中use ($request)）→ 改用use ($request->id)+ 延迟查库 - 全量数据库结果：
$users = User::all()→ 改为User::cursor()或chunk(200)，处理完立刻unset($chunk) - 大文件内容：
$content = file_get_contents('huge.json')→ 改用SplFileObject流式解析，或至少在json_decode()后立即unset($content)
gc_collect_cycles() 在 Webman 里的使用边界
它不是万能回收键，而是一把双刃剑：
- 仅对已进入根缓冲区（root buffer）的循环引用有效；若
gc_status()['roots'] === 0，调用也白费 - 频繁调用（如每次请求都跑）会拖慢性能，建议只在明确处理完一批嵌套对象后触发，例如批量导入结束时
- CLI 或自定义进程中可配合
gc_disable()+ 关键点gc_collect_cycles()+gc_enable()控制节奏，但 HTTP Worker 中不推荐关闭 GC - 注意：
gc_collect_cycles()返回的是本次回收的 zval 数量，返回 0 不代表没内存问题，可能只是没触发条件
真正有效的内存控制动作清单
别依赖“自动”，每个操作都要带清理意图：
- 中间件末尾或控制器返回前，显式
unset()所有临时大变量，包括$rawData、$parsedJson、$tempFiles - 静态缓存必须设 TTL，禁用
Cache::forever()；用Cache::put('key', $val, 300)替代static::$cache['key'] = $val - 数据库连接池默认复用，但闲置连接句柄仍占内存；可在请求结束时调用
DB::purge()（若使用 Laravel Scout/ORM）或自定义连接管理器主动 close - 避免在
onRequest回调中 new 大对象；改用工厂模式 + 单次生命周期对象，确保作用域一结束就自然销毁
最易被忽略的一点：Webman 的 Worker 进程不重启就不会清空全局符号表，哪怕你 unset() 了所有局部变量，一个漏掉的 static::$leak 就能让内存每小时涨几 MB——检查所有 static 属性和 global 变量的生命周期是否真的可控。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
